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)?"
All weakness is within you, As is all courage.
Typical development cycle is from 6 to 18 month. If public companies reported once a year there would be less pressure to "close a quarter" and less pressure to do shoddy work for that on elast deal.
<^>_<(ô ô)>_<^>
I kid you not, these things exist. I learned all about them in grad school.
TPS = Transaction Processing System, and TPS reports are a produced from them with many various options, interpretations, and meanings.
Keep in mind, this works best if you have a good dev team, a bit longer of a development timeline, and have management that understands the Q&D vs proper arguement. Or at least can be made to agree to it.
First off take the time to sit down with the development team, and make a project timeline. Use Gannt charts, management loves that, and it adds a real sense of professionalism to your dev schedule.
In developing your timeline, identify the "low hanging fruit" (a term I despise) which can be quickly adapted from existing code, as well as the items that both can, and cannot be written Q&D. Next, add in re-engineering of the Q&D sections of code to the timeline. Make sure that you find a balance where you have enough items developed early on that the PHBs have something to sell and boast about. It also helps if you make sure you don't do everything Q&D.
Stick to the timeline
If for some reason you can't, bring it up with the PHB and adjust the timeline.
A realllllly good way to make this work is to set out a bonus schedule for completion of certain phases of development before a certain time. This takes having a cool PHB, but it's a great way to keep motivated.
This is the way my last major dev project worked. And it worked *Very* well. Every phase of the project resulted in something the PHBs were happy with and could sell. As a developer and team leader I got a bonus for making sure my code was delivered on time. We even had a discretionary bonus pool that we could use to reward people who made an outstanding contribution to the project.
The real key here is to communicate with the PHBs, using their language (gannt charts), make sure you keep control of the development timeline, and most of all, stick to that timeline.
Karma: 0 (But I wield a mean +10 Vorpal Apathy)
Office Space, cult classic among cube workers, See also.
"Sic Semper Tyrannosaurus Rex."
It's a Mallrats reference; see the movie if you haven't. Actually, see Clerks first, the Mallrats, then Chasing Amy, then Dogma. If you like all of those, see Jay & Silent Bob Strike Back and An Evening With Kevin Smith.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
"Being a better programmer means being able to design more effective and trustworthy programs and knowing how to do that efficiently. It is about not wasting storage cells or machine cycles and about avoiding those complexities that increase the number of reasoning steps needed to keep the design under strict intellectual control. What is needed to achieve this goal, I can only describe as improving one's mathematical skills, where I use mathematics in the sense of "the art and science of effective reasoning". As a matter of fact, the challenges of designing high-quality programs and of designing high-quality proofs are very similar, so similar that I am no longer able to distinguish between the two: I see no meaningful difference between programming methodology and mathematical methodology in general. The long and the short of it is that the computer's ubiquity has made the ability to apply mathematical method more important than ever."
prof. dr. Edsger W. Dijkstra - EWD1209
-Adam
Several years ago, a guy on a Compuserve forum listed the seven facets he prioritizes at the beginning of every project. (I no longer have the post, so I can't give proper attribution, and these will be from memory.) He suggested that they should be considered and rearranged for each project. On any given project there will be two or three that stand out as particularly important.
1) Time to market
2) Cost to develop
3) Maintenance
4) Correctness/reliability
5) Performance
6) Extendibility/architecture
7) Features (or can a subset be used for the initial release)
At the beginning of the project the decision makers need to sit down and order this list for that particular project. Whenever it comes time to make a decision or tradeoff, they should compare it to the priority order determined for the project. If the tradeoff violates one of the top priorities then it should be considered with great care.
Some examples:
- In a PC flight sim game, Time to market and Cost to develop are probably the top two, and Features, and Performance are a little lower. Since game engines tend to turn over so quickly Maintenance and Extendibility are less important. And Correctness, while nice, really is one of the least important priority items (above a minimum reliability, of course.)
- In contrast, in an FAA flight training sim Correctness is probably the most important followed closely by Performance (mostly as it applies to Correctness.) Maintenance and Extendibility would prolly be important to a company that's building sims for a family of aircraft. But it might be less important for a company that's building a sim for a one-off class of aircraft such as a fighter. (Albeit, the ability to add new weapons systems and threats might bump this up.) Time to market and Cost to develop end up having to just fall out from the higher priorities.
- For many business applications, Maintenance tends to dominate the cost of using an app. For mission critical apps Correctness probably rivals Maintenance for top spot. And the rest will depend on the particular project.
And so on. As I said, I may be mis-remembering one or two of those priorities. But the general idea is valid. A list like this can help a team spell out ahead of time what's imperative, against which they can measure their decisions.