Why it takes more than a couple of good programmers to build great software
Why? Because building great software is more than just writing code. Writing code is the easy part. It’s much harder to:
- Understand the business drivers behind the project
- Generate insights into customer needs and market trends
- Think about the customer experience from the perspective of the end user
- Identify and focus on the most important priorities of the system
To build great software you have to understand more than what you’re building. You must also understand why you’re building the software and for whom.
And while what the software will do receives intense debate, there is almost no discussion given to what the software won’t do. The features you cut from a project can greatly improve the likelihood of project success, keep the team focused, and provide a streamlined experience for the end user.
All the while you’re working on why and whom, you still have to manage expectations of cost, delivery dates, and functionality.
Software project fail because teams:
- Over promise and under deliver
- Focus on “flashy” features and neglect core functionality
- Rush to start coding too soon and make design decisions that are costly down the road
- Assume that severa good programmers are the same as a few great ones
Seth’s article describes two approaches for your next project:
We don't have time to do it over so we have to spend the time to do it right.
Or, you can have some newbies hack something together real quick. Up to you.
Building great software is hard not because the programming or technology is difficult. It’s hard because you can’t be lazy in answering the questions as to why you need the project, how it’s going to be used, and what problems it solves for the end user.