The Average Lifespan of a Crisis

Have you ever asked your team to kick it into high-gear for an extended period of time in order to meet some major challenge?  Let me guess what happened…

They rose to the challenge!   Everyone stayed motivated, focused, and maybe even put in some overtime!  Great strides were made towards completing the goals.  But then after a week or so, that high-gear began to slip.  All that motivation and focus dwindled away.  A few weeks later you looked back and wondered if the project was any farther along than it would have been if you had just kept the status-quo.  

How did I know?  Because it always works that way.  "Why," you ask?  Well, it’s not because all developers are lazy.  Allow me explain.

Hiring by Personality-Type

As I have elaborated in some of my previous articles, the underlying personality of a developer should be of chief concern to you. Depending on the types of products that your team develops, you should have a desired ratio of personality-types among your engineers.  For instance, if you run a contracting service that develops websites for businesses, you will likely want a higher ratio of solution-providers on your team. If you develop pattern-recognition image-processing libraries, you likely want a higher ratio of puzzle-solvers.  Before hiring a new developer, you should seriously consider the type of developer of which you are currently most in need.

Component-Naming Rigor (CNR)

Whenever software engineers are asked to list the most difficult aspects of their jobs, the problem of coming up with good names for their components is always somewhere near the top of the list. Naming components is difficult for the same reasons that naming products is difficult. When you try to find a good name for a product, it can be a significant struggle to find one that is unique within the industry, memorable to the consumers, and yet still meaningful to everyone. Software engineers face the same predicament when naming their software components, but they go through it multiple times a week rather than just once a year. When they create a new class, type, data-structure, or module, they need to give it a name that is unique, memorable, and meaningful. If they fail to do so, they will not only confuse other developers, but they will even confuse themselves.

Embracing Inaccuracy

Perhaps nothing in our industry is more debated than time-estimates. Engineers hate time-estimates because they are never accurate, but everyone else desperately needs them. This tension has spawned a glut of software-development methodologies. At their core, most methodologies are all trying to tackle the same problem: time-estimates. Methodologies either claim to improve the accuracy of your estimates or they claim to lessen your dependency on estimates.

I'm not an expert on all of the various methodologies, but I do know one thing--everyone desperately wants to solve this problem. Everyone is willing to bend over backwards to achieve estimate-accuracy. If someone were able to legitimately solve this problem, the entire industry would immediately adopt the new methodology and its creator would become wildly rich. The fact that such a thing has not happened, yet, tells me all that I need to know. There is no solution, nor will there ever be one. I'm not saying that methodologies are worthless; I'm just saying that you shouldn't expect them to be a silver bullet.

So, should we cease making estimates altogether, as some have suggested? Of course not. That's absurd. Time-estimates are vital to the success of any software shop. So what is the solution? Realism. Don't waste precious energy trying to solve the unsolvable. Embrace the inaccuracy of time-estimates and learn to deal with it.

Rancid-Code Smell

Software, like food, can become rancid. Over the course of time, as new-features are added, adaptations to new technologies are made, and bugs are fixed, all software will begin to show its age. If software is designed well up-front, it will keep for a long time. Even the best designed code requires a fair amount of refactoring, of course, to keep it fresh, but, when it is maintained properly, well-designed code can keep for decades.

As I'm sure you are aware, all-too-often that is not the case. Too often, time is constrained, resources are low, talent is scarce, requirements are flawed, or budgets are tight. Whatever the reasons, most projects eventually become rancid and require either a major re-design or a total rewrite. No one wants to face it, but the truth is, some hopeless projects are even rancid right out of their packaging.

What do I mean by rancid? I mean code that's a waste of time--literally. I mean code that's costing you more time to fix, patch, and improve than if you were to just rewrite it from scratch. But how do you know? How can you, as a manager, determine that a project really is a hopeless cause? You certainly don't want to jump right in at the slightest hint of decay, and start redesigning perfectly salvageable projects. But if a project really is rancid, the longer you delay, the more damage you will cause. Not only will you waste valuable time, but you may also squander precious credibility with your clients as they ask for fixes and all you can offer them is failure after failure. So, again I ask, how do you recognize truly rancid software? What does rancid software smell like?  Here are some common rancid odors to look out for:

Dispassionate-Programmers

This article is one in a series. See the introduction here.

All of the personalities that I have presented thus far have been people who were impassioned in their work. They have been the kinds of people that became software engineers because there was some aspect of the job that they really loved. Most of those people would create software whether they were paid for it or not. That's not the case, though, with the type of developer that I am presenting today. Today I'm going to discuss the dispassionate ones. The word "dispassionate" can evoke some negative connotations, but that’s not the way I intend it. Sometimes dispassion is a great thing and is precisely what you need.

Solution-Providers

This article is one in a series. See the introduction here.

Solution-providers are passionate about what they do, but in a very different way. While the others kinds of developers that I've mentioned care deeply about the inner-workings of the software and how it is structured, solution-providers care about the user experience.

Don't be fooled, mind you; just because they are geared towards meeting the users' needs doesn't mean that they are necessarily good people-persons. Many of them are still the typical anti-social developer that you would hesitate to introduce to clients. It's not their people-skills that identify them as a solution-provider; it's what motivates them that matters.

Solution-providers get thrilled by the problems that their product is solving. They are often the feature-visionaries that dream-up all sorts of amazing things that the software could do. Where other impassioned developers tend to find roadblocks (e.g. "that would take too long", "we'd have to refactor our existing architecture to support it", "it would complicate deployment"), the solution-provider paves ahead full-speed because they are focused on the end-of-the-road. Often, to the shock (and sometimes horror) of the others, the solution-providers are usually capable of achieving their objectives in brilliant fashion.