I’m writing a brief for a new starter at the company.
I’ve pointed out the aims of what I want to achieve and now I’m writing some suggested (but not concrete) solutions.
For each of the aims, I’d like to suggest a fast, dirty method, and a slower, but more robust solution. I don’t mean ‘dirty’ as in uncommented and untabbed code, but simply as in faster, hackishy code.
I’m happy that the new starter takes whichever pathway they feel are necessary, and I feel my use of the word ‘dirty’ is going to put them off that particular solution. They’re probably going to try to impress the management, and I don’t want the ‘dirty’ solution to be a turn-off if that’s what they’re most comfortable with.
Can you help me decide on a slightly better terminology than dirty?
I aim to contrast between the hacky/fast solution (which is still valid) and a more robust, scalable solution. For a project as trivial as the one we’re producing, then either method will be accepted.
7
I don’t mean ‘dirty’ as in uncommented and untabbed code, but simply
as in faster, hackishy code.
How about duct tape programming?
http://www.joelonsoftware.com/items/2009/09/23.html
Based on your description, I believe it conveys well the believed advantages of your approach.
On the other hand, if it’s about prototyping (as @mouviciel suggested in a comment), then there’s still the concept of a proof-of-concept.
I believe you mean Technical Debt.
To explain, the “dirty” solution is solution that creates lots of this debt. The other solution is the one that doesn’t. Explaining what technical debt is is much better than comparing “bad” and “good” solution.
Basically, finding a name for the “dirty” solution might not be a problem. Because even this “dirty” solution might have it’s merits. Even worse, there might be more than two solutions, some “dirtier” than others. It is much better to compare those solutions based on how much effort they take and how much technical debt they incur. And if person understands technical debt, it becomes easier to differentiate between the probably multiple solutions.
2
If you have demonstrated the hackish code is indeed faster, just document that it was chosen for performance reasons. I would document this as a comment in the code. To do this you need to develop and test both solutions
If a quick and dirty solution was created for immediate cost reasons, present it as such. Do note that it introduces technical debt that may have to be repaid later. It has been my experience that in some cases the quick and dirty solution often cost more to test and get production ready than a properly coded solution. This is a case where early interest payments on the technical debt exceed the cost of the technical debt.
In other cases, the quick and dirty solutions end up including more code that a properly coded solution. They can be harder to understand and patch when necessary (part of the technical debt).
Be clear of the costs (including time to delivery, and reliability) of both solutions.
If there are problems with the quick and dirty solution, send them back to the starter with an appropriate timetable for solution. This may help them understand the cost of each approach. Good mentoring and code reviews may be appropriate as well.
The problem with saying dirty or hackish is that they are likely to think of your code like a dirty crawlspace. If it’s cheaper and no one is going to see it anyway then why should they care? You need to make it clear that the hackish solution is more like an unstable foundation. If you need to add on to the “building” then you will either have to fix the foundation (at greater cost than building it solid in the first place) or rebuild it altogether.
If you want to be sure that non-technical, business-minded individuals understand what they are choosing, communicate in terms of time/cost.
Rather than describing programming methods, I would use a term to describe the type of product you are producing. I would give options of quality code or throw-away code and describe the latter as being non-scalable, and non-maintainable. This makes it clear that adding on to the code will be more costly than rewriting it. The only reason for choosing such a solution is if you’re confident that the piece you are building will never change and are willing to pay the difference if you’re wrong.
Also consider that unless the decision makers are also programmers, they will not understand to what degree your hackish shortcuts will hamper change going forward. Only you know that. So it might be better if you get from them the estimated importance, longevity, and likelihood of change for a piece and make the technical decisions yourself.
Common terms are spikes, proof of concepts and prototypes.
0