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)?"
This is one reason why we as a society need to find ways to get rid of this need for greed and wealth and money in general. Otherwise things just keep running into the ground.
At least well I work process is what everyone agrees we should be doing. We are never, NEVER, given the time to completely follow the process. If you try you will either be working 60+ hour weeks or laid off for missing schedule too many times.
What I find funniest about our development process is that the people most adamant about putting things in place and documenting developement usually aren't having to do all the grunt work they are suggesting.
One should not theorize before one has data. -Sherlock Holmes-
That said, quick and dirty is always more fun.
Think about it--why does the Open Source model produce better code? Easy--if the developer isn't happy with the code, it doesn't go in. If the other developers aren't happy with one developer's code, s/he loses commit access. And, let's face it, if you're not happy with the code, it's probably not fit to be in the product.
So, in many ways, whether or not you're passionate about your code is a damn good way to judge whether or not you've completed code worthy of actually making it into a product. Customers and managers win when their developers have passion for the code they've written.
Jouster
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 don't know why people just assume that because one implementation didn't work, every variation on that implementation won't work. As it was, however, the Soviet Union did not get rid of money.
I make the effort to point out the pros and cons of spending more time - then let my customers decide what they want.
However, one thing that I do (for the quick jobs), is to send my customer a very short email (after agreeing on how the project will be done) summarizing our agreement to do a "quick as you can" project. Then, at the end of a project, I re-send the same email - remind them what they agreed to!
The same technique should work if you are an employee at a company.
Sometimes it is correct to do a "quick as you can project" - other times it is better to go for maximum quality. A quick project should produce correctly running code, but will be more difficult to maintain and modify in the future.
-Mark
The time and cost required to meet various goals, minus the opportunity costs of meeting previos goals at those quicker and dirtier levels of effort.
Every day I'm more convinced that quick and dirty is better because it gets code written which means it can be tested and often that means finding some aspect of the way the business is *really* run that was previously unknown.
Of course, I work doing business programming. If I drop one order a month at $40 that's no big deal really. Customer service will call that person, work it out by hand. Total cost to us is usually about 1 hour of customer service time. If I have to go fix that rare case to save $40/month and it costs the company $5k's worth of my time, that's not money well spent. We can process 99.9+% of all orders without a hitch. If I were coding for heart monitors however I might have a different attitude or at least much higher tolerances (I'm thinking 1 in a billion at least).
t
Tao of Programming, 3.2:
"There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, `What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.'"
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.
UGH... Talk about all the wrong things to do! The idea of fixing problems early is good, but your method of doing it sounds to be out of control.
There's no better way to guarantee that your product will never congeal than to be constantly changing it. What happens when the quirky code you just changed 5 minutes ago had just finished a month of testing and debugging? Or when your architectural re-write has a chain-reaction further downstream?
One of the most important things that good software development companies do is to track their defects, figure out where they came from and develop a plan for fixing them (or not...)
In the Apollo space program, the astronauts had a listing of every known bug in the computer software and what they needed to do when that bug got hit. You may ask "If they knew where these bugs were, why didn't they fix them?" It's a good question and I believe that the answer boiled down to "Because then you'd be introducing a bunch of bugs that you didn't know about."
Remember the time-money-quality (pick any 2) triangle.