My wife and I are both in the IT world. She is a project manager that for most of her working life has been employed by Fortune 100 companies. She works on software products that go into the marketplace and whose teams are counted in hundreds. It can be years before a product gets from conception to the marketplace. Her products are developed for the target business community.
I, on the other hand, am a somewhat knowledgeable Oracle guy whose biggest company has been 400 people if you count the part-timers. I work on projects where most times the number of team members can be counted on one hand. If we come up with an estimate of 3 months, management says "break it up" to shorten the development time. My projects are all internal endeavors whose primary goal is to help the business make more money or be more efficient.
She has always been an advocate of following a development process. A development process allows you to measure the progress of each phase of the project. Each phase of the project is defined by the work product that must be produced by the end of phase. If the process is followed, the resulting product has been good quality and usually makes a lot of money for the company.
My group works in what you could call the 80/20 methodology. We try to get 80% of the functionality into the users hands in a very short time. The other 20% of functionality will come when the business decides spending time developing a solution is cost effective and will bring greater benefit to the business than not doing it. Each project is short in nature and its success can be measured in how much time we can save or how much revenue it brings in. Sure, we have bugs in our software, but who doesn't?
At the end of the day, we both get the job done. She tries to explain how the process works even when milestones are not met. She can tell you how much of the phase is complete and the day it will be done with about 95% accuracy. I don't get it. I try to explain how my users expect results, not a document explaining what we will do. We need to solve a problem today, not 14 months from today. She doesn't get it. Is software utopia in the middle somewhere?
Subscribe to:
Post Comments (Atom)
4 comments:
It totally depends on the scope.
If she's involved in developing applications that will serve millions of users in hundreds of thousands of installations, then it will pay off to have rigorous process.
On the other hand, if it's a single customer and a single app, then all that process can just suck up time better spent getting it working.
Of course, it can be tough to figure out whether your particular project should be 80/20, 20/80 or somewhere in-between...
My thoughts:
Small quick-fix projects sometimes become longterm large projects. Bad or no planning at the outset can result in disaster later. We all do it, but it doesn't make it right.
Designing for 2 years, by which time the company has gone bust because you didn't get them 1 crappy sales report doesn't make sense.
I guess the idea should be to set some generic standards to work by. Preferred technologies and basic design patterns. At least that way the quick fixes still have some structure. It's basic stuff but it seems to be overlooked too often.
Cheers
Tim...
Jeff, if you're really interested in this topic, pick up a copy of the Mythical Man Month by Brooks, a sort of classic on the subject. Also check out Joel Spolsky's blog. He's got a book on Amazon which is #1 in Tech books #117 overall, pretty impressive. I just picked it up, and it's worth every penny
The Best Software Writing I: Selected and Introduced by Joel Spolsky. BTW, are you involved with NYOUG? I kind of recognize your name. I gave a talk on June 9th, rather late in the day "Open Source Tools for Oracle DBAs"
-Sean
Heavyweight Internet Group
Great, thanks for the info. Yes, I am involved with the NYOUG. Was there on the 9th, but missed your presentation.
Post a Comment