"Quick 'n Dirty" vs. "Correct and Proper"? 887
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)?"
Re:One reason why we need to absolve money (Score:3, Informative)
Management isn't always useless (Score:2, Informative)
1) You are much less likely to get in hot water for making the wrong decision. It would take a truly malicious boss to hold you accountable for a decision that he/she made.
2) There is a reasonable probability that your boss will have a better sense of the urgency of the relevant business issues than you do, given his communication with upper management. If you can clearly present the technical pros and cons, he can weigh those against the business pros and cons in a way that neither of you could do without information from the other.
3) Lets you stop agonizing and get back to coding.
-Tupshin
For What It's Worth, A Few Suggestions (Score:4, Informative)
Just out of curiousity, why was this not put in the "Ask Slashdot" section?
Anyway, even though I can't really say that I have had that sort of experience very often, but I'll do what I can to give a good answer to this question. I certainly hope that I won't find myself in these kinds of situations, although perhaps I'm being too optimistic. I understand that this happens quite often, and so I'm sure that you're not alone.
Anyway, while I can't suggest much, I doubt that many other people can. It's hard to get the PHBs to listen to you when you say the Q&D style solutions will only save time and money in the short term. If the anecdote that you gave is true, then maybe those PHBs will learn their lesson and not demand that so many shortcuts be taken. Shortcuts make for long delays, as they say.
I suppose that the best thing you can do is find ways to convince them that your ideas are worth listening to. As a matter of fact, a book titled The Pragmatic Programmer [amazon.com] not only goes into detail about good software practices, but how to convince those PHBs and fellow team members to listen to you. I suggest taking a look at it.
So anyway, good luck. This problem won't be easy to solve. Keep working on getting people to listen to your ideas and why it would be better than the Q&D approach in the long run. That's what I say.
What's the old adage? (Score:2, Informative)
Along the same lines, for software there is only one choice, overall, for software development.
- Cheap
- Fast
- Good
You can pick 2 of the 3, but not all 3. Cheap and fast is not good. Fast and good costs $$$. Good and cheap is never fast. You get the idea. It's just a fact about the software business.
Worse is Better (Score:5, Informative)
Re:No easy answer (Score:2, Informative)
Totally true, but you must also consider the advantages to proper design. The requirements and documentation often speeds up development by keeping the developers focused, and totally aware of what they are trying to accomplish. You shouldnt be writing anything at all without requirements. They dont have to be a novel, but enough to convey what needs to be done. And keep your documentation light, and it shouldnt intefere with your development progress. Take a middle ground approch unless the application can be written in less than a day or maybe a few days.
Not the money - quarterly reports. (Score:5, Informative)
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.
The meaning of TPS reports (Score:4, Informative)
TPS = Transaction Processing System, and TPS reports are a produced from them with many various options, interpretations, and meanings.
Re:No easy answer (Score:5, Informative)
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.
Office Space (Score:5, Informative)
Re:money (Score:3, Informative)
I would suggest writing a PAPER contract and getting official PAPER signoffs for each phase reached (yes, with their REAL signatures and REAL dates for REAL milestones reached....)
Make THEM follow a process that determines up-front the real, fixed business requirements, with cost estimates for hours worked, processes required by you/them, etc. Don't allow them to verbally request/require anything. Besides, a "strict" contract makes you look more professional. Put all expectations (money, time, documentation reqs., process reqs., business reqs., amendments, scope changes, cost increases, etc.) in writing and spell things out clearly and plainly, so both sides know exactly what to expect.
In other words, make it a legal, binding contract!
Then, under promise and over deliver. Go beyond what the paper contract expects of you whenever you can. This is how you make the customer happy. Happiness == over delivering on expectations; on the other hand, expectations "change without notice" when there is no paper contract....
If that means you come up with a Q&D that delivers early, goes under budget, etc., tell them that you are in prototype/alpha/beta stage and pretty up the product with the remaining time, even if it means redeveloping it The Right Way. If they are content with the Q&D, spend the rest of your time cleaning your code, making cosmetic changes, testing, and documenting everything.
We all know that it really takes 3-4 development cycles to do things The Right Way. And we know that around 70-80% of your actual development time is testing and debugging, if it's a good quality application done The Right Way. However, most business/marketing types look at any IT project as a cost and as a burden. If you can under promise on paper and over deliver your product, you're on you way to creating a Win/Win solution that makes people happy.
Development is an art; it's like the proverbial author of books who has a trash can full of wadded up type written pages before a manuscript gets written -- it may take them 10 tries to write just one page. It's sad that this message never seems to get through to the business decision makers.
They expect magic from those black boxes we'll call computers and expect wizards, whom we shall dub "developers," to perform miracles using black arts and mysterious incantations (a development cycle). In other words, expect them to be utterly clueless about your side of the fence. Use a paper contract to help dispel their myths and to clear up any confusion.
Having clearly defined expectations makes everyone, especially customers, happier. (If they change these expectations, there should be a clause in the contract that addresses extra time and money for alterations.) A contract should right-size everyone's expectations.
Now, I can hear flames from the Extreme Programming/Agile Programming people, telling me that customer expectations will change, but I'd still hold fast to the ideal of spelling out expectations on paper, including what to do in case of scope changes.
I also can hear the cry, "A contract will get me sued." A contract, whether verbal or paper can get you sued, either way. Verbal "contracts," however, change constantly and become hearsay.
(The other extreme is to over analyze. I've seen so many projects get into this quagmire. You know the old proverb that a camel is a horse designed by committee....)
I've learned this from the school of hard knocks. I too have been frustrated and have been burned badly by not having things clearly spelled out ahead of time.
Get a paper contract that makes everybody follow a balanced process.... Of course, we live in a perfect world, customers actually know what they want, world hunger is now solved, yada yada....
Re:It's like sex... (Score:5, Informative)
Edsger W. Dijkstra opined on this subject... (Score:5, Informative)
prof. dr. Edsger W. Dijkstra - EWD1209 [utexas.edu]
-Adam
Re:One reason why we need to absolve money (Score:3, Informative)
The culture of the Pacific Northwest Indians revolved around ostenatious display of wealth. Just one example out of many. Just because they didn't have money and most didn't have the concept of land as property, doesn't mean they didn't desire to accumulate wealth.
Re:One reason why we need to absolve money (Score:2, Informative)
You're falling for the noble savage BS. Yes, Native Americans liked accumulating wealth. Where do you think the Spanish got all the gold they shipped back home?
The more primitive the society, the more likely it is going to be non-accumulative. This isn't because it's better or more noble--it's because rampant accumulation in primitive situations causes the local environment to go to pieces. The Aztec society was just as greedy, mean, and nasty as any European one.
Re:One reason why we need to absolve money (Score:2, Informative)
Perhaps a micro-socialist system could be implemented for those who are out of a job? To give them a job within a co-op, where they can create their own jobs, train themselves from the resources made available; a safety net for the unemployed, at almost no cost to the government.
It's called a kibbutz [us-israel.org], and they're working quite well in Israel.
"Q&D" is an important tool (Score:4, Informative)
1. You have the ability to launch a project in the absence of a complete specification. If your customer is truly unable to describe what they want (until they see a Q&D system that gets part of the job done), then what is to be gained by dragging out the specifications process until any potential benefits have been lost? At the end of the day, the PHBs get the impression that "Our IT people couldn't get it done."
2: You have the built-in escape from a failed project. "This is just a prototype system that will help us build the specifications for a REAL system later... Let's deploy this little toy and learn from the experience." Of course, there is a very real chance that the "prototype" goes into real production. But if the project sucks, then it's super-easy to activate spin-control and launch the formal design of the "real" project. What is the escape route when you are $150K into the design/planning process and you suddenly realize that the goals are unattainable?
3. Consider the world of rapidly changing requirements, where the target moves faster than the geeks can write code. When does the traditional process catch up with the latest requirements? NEVER
4. Although documentation suffers, this is not always a bad thing. It certainly creates a dependency on the people who delivered the project, especially after a few of these little "science projects" are performing mission-critical tasks. Ask some of the currently unemployed geeks how their formal project plans and documentation made their employers feel safe in cutting the IT dept.
5. We have competitive issues arising from offshore outsourcers, and H1B labor. If there is one method that these people are in no position to emulate, it is the "Q&D, design while build" technique. The time zone and language barriers are both show-stoppers for Q&D projects.
Maybe the PHBs would stop looking to squeeze every IT dollar if we simply delivered useful projects a bit cheaper and alot quicker, even if the quality is not precisely as we might like. Hell, it sure works for Microsoft!
The Q&D method is inappropriate for large projects or inexperienced staff. There are skills for "guerilla tactics" that not all developers or managers have. Not every problem should be handled with Q&D methods, but there is a time and place for this kind of thing.
Which is the more satisfying job: leading a small group of IT commandos and attacking relatively small targets, or leading an army of morons in a war of attrition, armed with a 3-inch thick plan that is riddled with inconsistencies?
Years ago, I remember insisting on a formal approach and getting mostly criticism in return. Now I am flexible. Experience has shown me that I have to put aside professional pride when the immediate interests of my customer are better served by a band-aid approach. It's all very simple: If we take care of our customers, then we create positive karma, and some of that comes back to us. If we miss an opportunity to take care of a customer, then the competition takes care of them for us. Nobody was ever promoted because they held back a project until the specs and docs were complete. The risk of a missed opportunity is sky-high, whereas the risk of a half-assed project is often manageable, especially if the cost is kept low.
An example priority list (Score:5, Informative)
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.
Process Maturity and Process fixing (Score:3, Informative)
The solution to this is to fix the process, not the people. In this case your "quick and dirty" approach has been shown to work and needs to be integrated with the official processes. Write down the criteria for projects where this process should or should not be used. State the limitations, costs and risks clearly. In particular, it sounds like you have difficulty getting resources to go back and do it right, so put that into the process. Then get your shiny new process approved by the process police and inserted into the official manual.
There are two kinds of organisations that have process manuals and make sure they are followed. One is a mature organisation of CMM level 2 [cmu.edu] or above. The other is an immature organisation [grisha.ru] at level -1 or below, in which counterproductive processes are rigidly enforced. The test that distinguishes them is what happens when someone proposes an improvement to the process.
Good luck,
Paul.