“What are the 10 biggest software development pitfalls you have encountered?”

This question was posed to me recently, and as I tried to answer it I found myself smiling as I recalled the long list of projects, small and large, simple and complex, good and bad, that have helped shape me as a developer over the past three decades.  Most of my development career has been filled with long stretches of creativity, productivity and pride in the completion of a broad variety of useful and sometimes ‘special’ projects.  But there have also been some hard lessons learned along the way, and some conclusions I can draw from the experiences.  How is my short list of Software Development Pitfalls:

1. “Listening but not Hearing”

Software developers often interact with users or subject matter experts who want a great software solution but don’t know how to express their needs and challenges.  A good software developer needs to be able to not only ‘listen’ to their clients, but also ‘hear’ what their clients are saying, ‘hear’ their challenges and needs, and be able to reflect an interpretation so that a quality solution can be designed and implemented with the client’s full understanding and blessing.  ‘Hearing’ really means looking under the surface, behind the curtain, and gaining genuine insight and understanding of the client’s application and objectives – and then using this knowledge to craft the best solution with the available resources.  When the analyst or developer listens, but does not hear, assumptions are made, poor solutions get implemented and nobody wins.

2. “Confusing priority and urgency”

One of the biggest challenges as a developer is managing the broad set of tasks, responsibilities and coding demands of a project, all of which seem important and urgent all at once.  A few years ago Stephen Covey wrote a great book on “The 7 Habits of Highly Effective People” in which he referred to the Eisenhower Matrix as a simple but brilliant method for prioritizing what is important and what is urgent.  He called it the “Eisenhower Matrix” because of a quote from the 34th president of the United States, Dwight D Eisenhower in which he said: “I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent”.  Covey took this quote and developed a very popular task management tool known as the “Eisenhower Matrix”, which prioritizes tasks by urgency and importance into four quadrants:

Using this approach to managing project tasks allows the developer to assess tasks based on importance and urgency, and then delegate tasks to the assigned quadrant categories, prioritizing them in a way that is effective and productive.  Best of all, it identifies distractions and unnecessary tasks, which are the bane of all software developers.

3. “Terrible Time Estimates”

Developing a time estimate for project tasks is a crucial part of project planning and implementation.  The time estimates need to be as accurate as possible to ensure a project stays on track.  This is especially important if tasks need to be done sequentially and are therefore dependent on each other – in these cases, a delayed task can cause a development bottleneck that results in lost productivity and additional project expenses – not to mention the loss of credibility when the entire project delivery date takes a hit and you have to explain to your client why you are late.  The best approach to making good time estimates is a three-pronged approach:

1. Make time estimates based on prior experience.  There is nothing better than experience for making wise decisions.  Try to use experienced developers on the team to review project completion timelines on a task-by-task basis and allow these developers to base their estimates on prior experiences with similar project tasks.
2. Be conservative rather than optimistic.  As developers we look at problems and can see the solutions and we want to provide an optimistic timeline that will make us look brilliant.   More often than not, the optimistic projection will get us in trouble because it leaves no room for error – always remember that it is better to be conservative and realistic, and beat the projected timeline, than to be optimistic but late on the deliverables.
3. Build in a 20% contingency factor – in other words, once you have your time estimate established, add an additional 20% so that any unforeseen delays will not derail the project timeline.  Don’t make the mistake of leaving this contingency out – it is your lifeline that maintains project completion credibility.

4. “Letting Everyone Else drive our schedules”

All projects have a variety of team members in various roles.   Broadly speaking these roles can be thought of as the ‘Tech Team’ role and ‘Everyone Else’.  Often there is great pressure placed on a project by the ‘Everyone Else’ roles, which could also include the client who wants the project done in the shortest possible time for the lowest possible cost.  It is imperative that those of us in the Tech Team role ignore the pressures placed on us by Everyone Else.  Our schedule must be driven by our accurate time estimates and we must not alter that schedule based on the demands of Everyone Else.  If management asks us to reconsider a timeline, the best response would always be to ask for more resources – but these discussions must be done up front before we have buckled to the outside pressure to shorten our development schedules.

5. “Don’t be seduced by the Quick Fix”

How often have we been tempted, as developers, to write a ‘Quick Fix’ that circumvents our standard code practices because of the need to solve an immediate and potentially costly problem?  The key here is to realize that there really is no ‘Quick Fix’, because ultimately we have to come back and revisit, redesign and rewrite the code to make it work properly and conform to our standards.  Stay away from the Quick Fix as much as possible, but if the project or application absolutely cannot continue to function without the immediate Quick Fix, then by all means take the plunge and implement the Quick Fix.  But the caveat is that after a Quick Fix has been implemented, it is crucial to document what happened, document the preferred code-standard solution, and to schedule the implementation of that solution.   If, we do not do this, and if we ‘forget’ about it, Murphy’s Law will come back to haunt us at the worst possible time – and the longer we wait to fix the Quick Fix, the harder and more expensive it becomes to correct.

6. “Don’t follow coding standards or Best Practices”

Every development team should implement and follow a prescribed coding standards approach to software development.  Coding standards are vital to product development success because they help to ensure a uniform approach to coding that enhances product safety, security and reliability, and makes solutions flexible, reusable and maintainable.  Consistent code quality is the Holy Grail of software development – because it means that regardless of who writes the code, it will adhere to the highest standards set by the team.  This includes a comprehensive commitment to documenting the code and using document coding tools and standards that assist in maintaining a robust, progressive and informative code base.

7. “Don’t share the knowledge…”

In today’s dynamic software development environment, the best teams are those that understand the value of sharing the knowledge of the software, coding standards, and the project.  “Sharing” should also include the process of sharing documentation, code comments, peer reviews — and even “notes to self” that might someday be helpful to your future self when you revisit a project or a particularly difficult piece of software.  When developers hoard their knowledge to make themselves more valuable, they are operating under a misguided sense of what is important to the project and they essentially stifle the progress of their teammates.  A good project manager recognizes the value of shared knowledge and will strive to encourage this at every turn.  Far better to have a team of many experts that share willingly versus a hierarchy where everything depends on one or two individuals.

8. “Stuck in the old ways”

Software languages, tools, techniques and approaches are in constant flux.  To continue to produce quality software in a dynamic and demanding marketplace, a development team must commit to an ongoing re-education of their staff and resources.  A good software developer is not locked into the old ways of doing things and is always thirsty, always seeking a better solution, a better tool, a unique approach that best solves the problem.  Software languages, tools, techniques and approaches are in constant flux.  To continue to produce quality software in a dynamic and demanding marketplace, a development team must commit to an ongoing re-education of their staff and resources.

9. “Not leveraging peer code reviews”

Quality software development teams understand the value and importance of quality peer code reviews, which can be used to not only review complex software solutions, but to also ensure that code is being written using a best practices approach.  On teams where certain developers might have deeper levels of system and code knowledge, either because of experience or because they actually wrote a relative module, it is often highly productive to include these developer resources as part of a code review process.  Developers need to recognize that a code review process is an opportunity to fast track their own knowledge of the system and to achieve a better overall software solution.

10. “Ignoring the ‘win’ and the ‘well-done’”

The best software development teams are quick to encourage, circulate and share the applause when the team or a team member produces a quality solution.  As developers we don’t often receive the 'thank you’ we deserve for the brilliant solutions we create – and who better to understand our contribution than our own team members?  Teams that celebrate their wins and express their gratitude and respect to each other foster a sense of achievement and pride that helps sustain a strong and positive working environment.

Prevailing past pitfalls…

Most software developers have experienced some of the above, and most could probably add one or two additional pitfalls of their own.  The bottom line is this:  if we are committed to our software development teams, and committed to delivering world class software for our clients, we must take careful steps to ensure that we are aware of pitfalls and that we are constantly striving to create a Best Practices workplace environment.  And if a pitfall does pummel us, we must not panic, and instead must prevail past it with persistent precision.