Slashdot Mirror
"Quick 'n Dirty" vs. "Correct and Proper"?
A not-so Anonymous Coward enters this query: "I keep finding myself on projects where a quick and dirty solution will bring in money for the company, and a correct (ie, properly documented, well engineered, process followed, etc) solution will get us left in the dust. When the Q&D solution succeeds, I'm left trying to explain why it can't be the FINAL solution (to PHBs and Marketroids that were fully informed of the situation prior to any work getting done). Most recently, work I did in record time was used to help bring in several large contracts, and then I found myself in hot water for not having followed process et al. So, to Slashdot: is it better to do the quick thing and greatly increase the chance of $uccess now, or to do the correct thing and avoid pain later (assuming there is money to pay for the pain later)?"
And with layoffs coming every couple of months, I sure as heck don't want to be tech lead on the project that missed its market window because I insisted on perfection. I try to balance risk/reward, taking shortcuts on the less risky parts, negotiating to eliminate unnecessary functionality, and doing whole-hog process on critical system components.
I can only speak from my experience at my current employer. The company is founded by two CS PhDs, so no PHB trouble. We don't follow any formal process in our development, we don't even comment the code, which really pissed me off in the beginning. However, what we do rather successfully is to make everything as simple as possible.
If you run over some code and you figure it could be done simpler, even if it's not your code, do it simpler NOW. If you find something has been done in a quirky way, fix it NOW. The general rule is that the code has to be understood for the next let's say ten years. We have strict coding guidelines regarding method naming and variable naming. If names are not fully self-explanatory they are replaced immediately even if they're scattered through the whole application. If critical parts like persistence suffer from a bad architecture, it is fixed immediately no matter how much work the rewriting involves. Finally, this leads to very understandable code and once you've understood the general application architecture the code is very easy to read, very clean and mostly pretty correct. There are hardly any quick hacks, sometimes they are inevitable though, to circumvent bugs in the software environment for example.
If you're suffering from lay-offs and don't mind 170 days of rain per year, consider think-cell (I'm only a student employee myself, neither owner nor partner, so it's not advertisement, just advice).
"Quick & Dirty" is not necessarily the opposite of doing things properly.
Faced with a choice between "quick and dirty" versus a long process that is not even ready to produce code until everything is known, there isn't a company in the world who won't go with quick and dirty.
The long elaborate process doesn't really work anyway. The world changes too quickly.
What you need is a methodology which emphasizes development in stages. XP (Extreme Programming) and Feature Driven Design (a variant of UML) are two examples.
The important thing is to identify your fundamental interfaces, make sure those are right. Document them. And then feel free to code each and every component as "quick and dirty" as you ever imagined.
If you did the first part right, you can replace components later, add new components, etc.
If you didn't document your interfaces well... you've just delayed the failure of the project through absurd amounts of overtime. You have zero chance of longterm success.
It isn't even necessary to always have a grand master plan. Well documented simple interfaces can frequently be extended in ways that weren't anticipated when they were first created. But you have to focus on the interfaces - that's what allows for evolution.
The most obvious example of this is the Internet itself. The OSI stack was trying to do things "thoroughly", IP just wanted to be "flexible". Flexible can be developed cheaply, and unlike either pedanticly thorough methodologies or complete anarchy, has a chance to build itself up one useful piece at a time.