Projects Do not Fail for Technical Reasons

They Fail for People/Communication Reasons.

What the analysts and pundits don't take into account is how technical choices aid or impede communication. One of the largest problems faced by IT shops is churn - there is always a new silver bullet technology that will solve all the problems. What this means is that most IT shops never gain enough expertise in any given set of tools to be truly productive; they are always moving on to new tools that will theoretically solve the problems better than the old ones.

What developers need is tools that will help improve communication - both between themselves, and between their customers. If the technologies they choose to implement in are complex, then developers will consistently be speaking jargon - solving technical problems instead of business problems. If, on the other hand, developers are given tools that are not complex, they will spend more time solving (and discussing) business problems instead of technical issues. To use a trite example, simpler tools will allow developers to discuss requirements instead of compiler errors. Tools that mostly get out of the way and allow developers to express the intent of their customers are better; tools that layer on complexity and arcane rules stand in the way, and prevent or delay these expressions of intent.

One thing to bear in mind is research from psychology. People can, on average, keep 7 (+/- 2) things in mind at once. Adding to the number of things that need to be kept in mind is not really possible - it's a human limitation. Choosing tools and/or processes that insist on throwing complexity directly in the face of a developer are as sure a recipe for failure as is possible - simply based on the reality of human capabilities. What does this mean? It means that choosing a strict process with many steps and lots of documentary steps is not going to work - the sheer complexity of the process will over burden the average developer. Likewise, choosing a set of development tools that require a steep learning curve will add problems. It will take longer for developers to internalize the rules well enough to be productive. It's a simple fact that projects will not normally be staffed with as many experienced people as you would like - so choosing technologies that make things simpler will get you started sooner.

Where does this drive us?

Processes - pick an agile methodology. A heavyweight, process driven methodology will wear developers down and prevent progress.

Tools - pick an agile toolset. A set of complex tools will likewise wear developers down and prevent progress.

What satisfies these?

Visit the Agile Alliance for tips on process. For tools, take a look at Smalltalk. It's no secret that the Agile Alliance leaders are virtually all from the Smalltalk world; there's a reason for that. Smalltalk is simple and powerful. A beginner can learn it in minutes, and an expert can express a design clearly and tersely. One complaint you'll hear is that Smalltalk has a large learning curve. And Java or C# don't? Smalltalk has 5 reserved words and syntax that fits on a 3x5 card. C# and Java have 50+ reserved words and very complex syntactical rules. It simply is not the case that Smalltalk is harder to learn.

- James Robertson