Recently there’s been a lot of hand-wringing over programmer’s oaths, user needs, and what the hell we’re doing as a profession. Eric Leong chimed in with an interesting breakdown of “product developers” and “technical developers”.
But let’s forget about individuals for a minute. Let’s talk about teams. A team might be an entire startup, or a division of a company, or a product team, but it includes all of the people responsible for delivering a software product.
The team has to hit four goals:
Make money
Everybody’s gotta eat.
Make users lives better
Kathy Sierra has a whole book arguing that this is the most important piece of the puzzle.
Make a quality product
Software conferences focus on this goal - creating things that work well and look beautiful.
Be a quality team
Hiring, diversity, education, mentoring, development process, management, politics - all of the the things that keep the people working smoothly together.
–
In an ideal situation, these goals naturally flow into one another. The team has great people, an effective process, and works well together. They build a product that’s “high quality” to them - whether that means clean code, beautiful design, lots of features, or anything. Their users appreciate that high quality product, because their needs match what the team is delivering. Then the users shower them with money, since the users happen to be rich.
In the real world, there’s friction between these steps. Make an extra buck by upselling your users with features they don’t need. Save your users time with a feature delivered today, but at the price of technical debt. Deliver a high-quality product on time, but burn out your team in the process. Be a great place to work, until the company goes under.
So it’s all about tradeoffs and focus, not oaths and absolutes.