For most of us, sales make the world go around. I cannot pay my mortgage, college tuition, or that Caribbean trip that I have planned with hypothetical money. This requires real money, which usually comes from sales to a tangible customer. Forget that at your peril.
I have heard, on more than one occasion and from a variety of sources, that the development team should drive deadlines. Bogus! Everyone should have a seat at the scheduling table for setting deadlines: management, sales, marketing, and you. The best schedule is a collaboration that balances technical with business and customer needs. If a company exhausts its available funds before the product is complete, who benefits? How useful is your product when competitors deliver a product with slightly less features a year earlier but captured the majority of the market share? Your competitors will be on that weeklong Caribbean vacation while you are on a one-day trip to the Air Force museum in Dayton.
Do not over-engineer. Over-engineering usually entails needless complexity and the implementation of features that almost assuredly the customer does not require. We all know developers, when asked to build a toaster, would deliver the space shuttle. Without a doubt, this would be the best toaster in the universe. However, customers only wanted to mildly burn bread. They never intended to fly their toaster to the moon—even though that is a cool feature. Fight the temptation to over-engineer. The additional complexity will introduce bugs (the kinds that are hard to find) and delay product release, and the code is most likely not maintainable. Plus, you will give your manager and peers heartburn. Over-engineering will exhaust available capital, which is rarely an unlimited resource.
This section is best introduced with a passage from Catch-22. Catch-22 is a book written by Joseph Heller that later became a popular movie.
"Can you ground him?"
"I sure can but first he has to ask me to. That’s part of the rule."
"Then why doesn’t he ask you to?"
"Because he’s crazy," Doc Daneeka said. "He has to be crazy to keep flying combat missions after all the close calls he’s had. Sure I can ground Orr. But first he has to ask me to."
"That’s all he has to do to be grounded?"
"That’s all. Let him ask me."
"And then you can ground him?" Yossarian asked.
"No, then I can’t ground him."
"You mean there’s a catch?"
"Sure there is a catch," Doc Daneeka replied. "Catch-22. Anyone who wants to get out of combat duty isn’t really crazy."
This conversation takes place at a military base toward the end of World War II. Yossarian is a bombardier who should be rotated home after reaching a certain number of bombing missions. One problem is the base colonel keeps raising the number of missions required to return home much to the frustration of everyone. Similarly, when the feature set is not frozen, developer morale is affected. Particularly in the later phases of product development, this is a sure indicator of a lack of discipline and inexperience project management. Developer morale will suffer as the goal line is perpetually extended. Fatigue will occur, and the quality of product development will be affected. More bugs are created at this time than at any other time. In addition, feature creep makes meeting deadlines nearly impossible, which has an obvious adverse impact on the budget. The following is quote from the Catch-22 movie.
Yossarian: If he raises the number of missions again, I swear to God, I’ll help you kill him.
Dobbs: Really?
Yossarian: I swear.
Dobbs: Well, that’s very reasonable of you.
View each new feature as a potential harbinger of the plague. That should provide the proper level of skepticism for assessing the benefit of adding a new feature. Each new feature is a harbinger of future bugs. Of course, this means extra development costs and missed deadlines. Now even that trip to Dayton seems remote. In addition, you are now spending more time on new features and related problems and less on your current code base. For this reason, the quality of your current code base will begin to suffer also.
There are two groups of developers. The first group lives in an infinite world where there is endless time to implement additional features. These developers have never seen a feature they did not like. You can also include some managers and marketing people in this group. The other group comprises developers who are overly ambitious and optimistic. They always commit to doing twice as much as necessary in half the required time. Developers like this never plan for a weekend, vacations, or even bathroom breaks. Of course, these people perennially miss deadlines. More importantly, their code is probably of lesser quality than anyone else on the team. They are often overcommitted and overwhelmed, which translates to poorly written code.
If developers have too much "I" in their vocabulary (such as the following statements) and not enough "the customer," be concerned. They are likely to add features that no one wants.
That is a feature I would like.
I find that to be very cool. Let us implement that.
If I were the customer, this is what I would like.
Focus on key features. Prioritize the features to determine which features are the key features. Dedicate your resources proportionally to the high-priority features and lesser for low-priority resources. If you poorly implement the key features, the customer will never use the other features. Customers will switch to a competitor’s product before then. Like most, I use Microsoft Outlook primarily to send and receive e-mail. There are plenty of other features, but those are the key features from the perspective of a user. If those features do not work, I would not use Microsoft Outlook, regardless of how great those other features might be. For those reasons, focus your efforts on the primary features and do not dilute your effort with additional features.