Programmers Are Mini-Project Managers
From Programmer 97-things
Every programmer has experienced this at one time or another where someone asked them to just "whip something up."
The project could initially appear as simple as a three-page web site, but when you actually sit down and talk with the customer, you realize they want to build an e-commerce system with résumé-building capabilities, a forum, and a CMS (Content Management System) with all the bells and whistles.
Oh, and they are preparing to launch in a month.
Of course, we can't all take out a rolled-up newspaper and smack them on the nose saying "No!" But instead of freaking out, most professional programmers immediately ask the following questions:
- How much time is available to complete the project? (Time)
- How good is the code you write? (Quality)
- How much is available in the budget for this project? (Cost)
- What features are included before the launch? (Scope)
I know these questions are moving towards "project management" territory, but every programmer who has been in the industry for a long period of time understands that these factors creep into every single program they write, whether it's a fat client or a web application.
These four important factors determine whether a programming team (whether one member or twenty) will complete a project successfully or fail miserably in the customer's eyes:
- Time: How much time is available for coding, testing, and deployment? If there isn't enough time for coding, testing, or deployment, this may sacrifice quality because you are pressured through the tasks and may produce inefficient code.
- Quality: If you want maintainable code, you may lose time and the cost may increase over an approach that compromises quality. On the other hand, the technical debt of compromising quality is also likely to lose time later therefore increasing cost in the long-term.
- Cost: If you want it cheap, you may have a coding frenzy with a lot of unmaintainable code and gain some time, but the quality of the product will suffer.
- Scope: If you want to release a quality product, you may need to focus on the features that really matter to the user. Perform a temporary feature toss to release the product on time and save the other features for a future update.
The key to overcoming these "rectangle of tangles" is to ask the user some questions about the project. If you ask enough questions, you'll become more comfortable with what the user wants. The more comfortable you are with understanding what the user wants, the more comfortable it is to know what key components will be the hardest and easiest to create.
If you understand what the user is looking for, you will have an idea of how long it will take to finish a project (Time). Based on the time factor, you can gradually move towards a dollar estimate of the project (Cost) because you know what features need to be built (Scope). Finally, based on your skill set (since you are a professional programmer), you should be able to produce a really high-quality product.
This work is licensed under a Creative Commons Attribution 3