Software is finding its way into almost every aspect of our daily lives. Everything from our kitchen appliances and entertainment systems to our automobiles is controlled by software. Regrettably, much of that software suffers from poor design, UX inconsistencies, obvious defects, and sluggish performance.
I focus this blog on enterprise software development because it’s a complex topic that interests me. I favor agile approaches like Scrum, Kanban, Lean and XP because they are more adaptive than traditional command-and-control techniques. Managing complexity demands adaptability.
Why is commercial software so bad so often?
- Writing software is easy. The barriers to entry are low. Anyone can do it.
- Building complex software systems is ten times more difficult than #1.
- Creating great software solutions can be ten times more difficult than #2.
Looking for an easy way to earn a living? Look somewhere else … please!
Here is a brief rundown of the key characteristics that can make building great software so difficult. Each characteristic begins with the simple and evolves to the formidable. If everything about your project is simple, stop reading this blog and start writing code. Your risks are low.
As your project approaches the formidable in any area, your risks increase dramatically — not just by a factor of 2-4. Risks increase by factors of 10-100 as you go from simple to formidable. Multiple formidable challenges put your project at substantial risk of never achieving greatness. You may deliver a result but it won’t be great unless you address the challenges firmly.
1. Problem Space:
- Well-known and well understood (similar problems have been solved before by the team)
- Well-known but not understood (similar problems have been solved before by other teams)
- New with few unknowns (problem has not been solved before but the team understands it well)
- New with many unknowns (problem has not been solved before and the team is challenged)
2. Solution Scope:
- Single user
- Small group (up to 50 users)
- Large group (up to 500 users)
- Very large group (up to 5,000 users)
- Multiple groups (up to 50,000 users)
- Unlimited (over 50,000 users)
3. Team Composition:
- Single corporate unit (team members report to the same person)
- Multiple corporate units (team members report to different people)
- Multiple companies (team members work for different companies)
- Vendor / client relationships (consultants and clients on the same team)
4. Team Experience:
- Experienced in the problem space (mature team with a track record in the domain)
- Experienced but not in the problem space (mature team entering a new domain)
- Inexperienced (junior team)
5. Team Size:
- Single developer
- Small team (up to 9 people)
- Large team (up to 25 people)
- Multiple teams (up to 250 people)
- Amalgamation of teams (over 250 people)
6. Development Approach:
- Ad hoc (little structure or discipline)
- Minimalist agile (basic Scrum or equivalent)
- Structured agile (advanced techniques from Scrum, Kanban, Lean and XP)
- Controlled and phased (traditional waterfall)
- Regulated (tightly controlled process with lots of documentation and approval cycles)
7. Software Architecture:
- Single component
- Multiple components integrated in a single executable
- Single executable with multiple modules (e.g. services, drivers, libraries, etc.)
- Multiple executables (running on a single hardware system)
- Distributed executables (running on multiple hardware systems)
8. Technologies and Development Tools:
- Mature and proven (widely used)
- Relatively new but proven (not widely used but stable)
- New and unproven (leading edge)
Where does your project fit? What about your team? Have I missed anything? Please share your thoughts.
photo credit: kevin dooley via photopin cc