Twitter   RSS Feed   LinkedIn
« Making Secure Passwords | Main | Rethinking Your Business (Part 3) »
Monday
Mar122012

Building Great Software

Why it takes more than a couple of good programmers to build great software

Seth Godin wrote an interesting blog post about The Extraordinary Software Development Manager.  He describes how it takes more than a good programmer to build and deliver 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.