Monday, March 23, 2015

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.

Tuesday, March 10, 2015

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.

Tuesday, March 3, 2015

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: