10 common ways software projects fail

A paradoxical scenario plays out all too regularly in a good number of software development studios. The organization hires great developers who have done great things in the past and put them on a project only for them to woefully fail.

Before you go on and judge the team as incompetent perhaps its time to look inward and see maybe the teams fail because of your own managers and the systems under which the developers work in.

In this entry we will be looking at some of the most common ways that software projects fail owing to process failures.

Analysis paralysis

Knowing exactly what is to be built plays right into our need for control. Control over the budget, over the schedule and the time. For all but the most trivial projects, this endeavour is doomed to fail. The reasons for this inevitability are varied, I have previously talked about it in One design to rule them all.

Thankfully the industry has elegantly solved this problem. The answer lies in agile software development. In agile and its practises (XP, Scrum) you don’t need to know everything. You leave room for flexibility as your team knows more and more about the project. See Scrum in 4 easy steps.

Negative peer influence

Throughout our formative years we were warned of this beast called peer pressure. Usually was related to drug abuse, teenage pregnancy, crime and all other decadence of youth.

Yet in our professional lives peer pressure is still as real and even more powerful.

The truth is, the opinion of the group will more likely be shaped by the loudest mouth around. This can negatively affect productivity of your most valuable team members especially if they are the silent type. In case you are wondering a good number of developers are the silent type.

To overcome this kind of peer influence. You need to ensure that your decision making process actively defends against it. An example would be by using anonymous feedback mechanisms and acting quickly to discipline errant members.

Silos

It is natural for team members to feel closer to each other as compared to the other members in the organization. This tendency however can rapidly degenerate into lack of respect or even worse outright hostility between teams.

To beat silos you need to encourage cross team collaboration in a way that highlights the strengths of the team. Self organizing teams working in flat hierarchies are the ones most likely to deliver this kind of collaboration.

Vendor lock in

It’s very easy to get tied into a particular vendor products especially when the products initially boost your production speed. When this happens you lose agility and are forced to build your products around what the vendor allows you.

Some level of commitment will obviously be needed to make any progress but ensure to have done proper due deligence and design your own solution in such a way that the dependency is clear. See Hexagonal architecture.

Over engineering

By and large developers are smart people. Left to their own means they will come up with the most complex design possible for the particular problem you are trying to solve.

Unfortunately the cost of implementing the design may just not be worth it especially for smaller projects or on the onset when the product is not yet clearly defined.

A close cousin to over engineering is gold plating. In this case, the developers put in extra features in the hope of impressing the boss or the client.The strategy largely fails as the client will either be confused by the cruft or refuse to pay for the time used to develop it.

Comprehensive documentation

Documentation is critical to a successful product. Over documentation however steals valuable developer time. It is also worthwhile to note that end users expect the product to be simple enough to use without referring to any documentation.

Invest in good UX to mitigate the need for more documentation, let the product and the code self document. See Name well or go home.

Procrastination

On project onset you likely have months to get the work done. In this cases procrastination sets in

Then towards the end of the project the developers are suddenly on fire working 100 hour weeks to get the project done. This is an unhealthy practise that leads to a phenomenon called the Death March.

The death march is an unfortunate situation where everyone in the team knows the project is headed for failure but continue on anyways.

To deal with this, work needs to be done in defined time box. Scrum allows for this by the practise of arranging work in sprints.

Super developer

Believe it or not super developers are not good team members. The reason is the rest of the team starts blindly trusting on the developer’s super human technical ability to get things done.

Very quickly, this developer will turn into a bottleneck for the entire team grinding work to a halt.

In addition the reverence paid to the super developer may mean you miss out on the creativity of the rest of the team as they wait for all the answers to come from the one person.

If in this situation the best course would be to ensure the super developer shares their knowledge with the rest of the team.

Poor communication strategy

The best way for humans to communicate is face to face period. Using email as the primary means of communication means a lot of the nuances get lost in translation.

In case you run a distributed team, try create an environment that imitates a co working space as much as possible. Tools like slack and hangouts are perfect for this task.

Bad manager

Bad managers come in many forms. The most common being the micro manager and the hands off manager. Both types of managers are bad for the team.

This types of managers drain the energy from the team and suppress their creativity.

Again agile techniques with the concept of self organizing teams and natural authority come into play. Here you let the team be responsible for its own success and let positive peer pressure work for you.

Have any of the factors mentioned above affected your projects? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Common barriers to information hiding

A core tenet of software engineering is information hiding. OOP rose in popularity owing to how well it was able to implement the concept.

When you have information hiding working for you, an entire class of problems simply disappear. I have previously talked about the concept of complexity in software The heart of software engineering and how to manage dependencies Isolating change in software projects. Today we will be looking at some of the barriers that you will likely face in this endeavour.

Hard code

Yes code can in fact become hard. Or more precisely rigid. This happens when you have design that necessitates multiple edits to the codebase for simple changes.

An example I like to use is the case of the tax rate. Since it’s a figure that very rarely changes you will be tempted to simply use the value throughout with statements such as:

employee_net = employee_gross - employee_gross * 0.3

That statement does not seem dangerous at all, I mean at worst you could do a quick search and replace if need be. And that maybe true but what if you had reference to another 0.3?

expected_annual_return = last_year_value * 10.3

Issues like that line the path to programmer hell.

Circular dependencies

This is a nefarious one. It’s power comes from the fact that at the surface it looks like great engineering.

Lets say you have a code such as:

<?php 

class User(){
  
  function getUserData($username){
    //fetch db data logic
  }
  function changeSubscription($username){
    $login = new Login();
    if($login->checkLoggedIn()){
      //Upgrade subscription level
    }
  }
  
}
class Login(){
  function loginUser($username,$password){
    $user = new User();
    $data = $user->getUserData($username);
    if($data['password'] == Hash::value($password)){
      //user login logic
    }
  }
  function checkLoggedIn($username){
   
    //logic to check if user is online
  }
}

Hidden in the code is a circular dependency. Now you have no way of testing the User class without having first written the Login class and vice versa.

Global data

So now you have moved your constants out and now save them as global information. But you have done more than just move the constants, you have also moved items you figure get used a lot by different classes out to the global space.

The challenge that this gives you is that you now have to consider what other methods that use the same global variable are doing to it as you are writing this method. You maybe the same developer that wrote both methods, but by forcing yourself to hold this information in your head, you have inadvertently created a fertile ground for bugs.

Instead consider making use of class level variables. While the dependency is still  there, now it is made explicit. You can see at a glance how exactly all the other routines interact with the data.

How do you hide information in your own projects? Reach out to me on twitter at @jchex or in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

5 ways to keep your client in the loop

Software is expensive to develop. We all know that and are more than happy to charge our clients our true worth. For worthy clients the amount is not the issue, the project will likely net them multiples of whatever you charge.

Imagine yourself as a businessperson running your own bakery. You sell cakes to the local neighbourhood residents. You meet this awesome developer who promises you that they can boost your business by 100* if only you could enable customers to order online. This sounds like a good idea and you are all in, you invest 5 month income worth of your business to building the product.

A timeline of 8 months is agreed, contracts are signed, deposits are paid everyone is happy.

One month down the line you walk by the developers office to see the progress done so far. The developer tells you that they still are setting things up but are fully confident they will make the deadline.

3 months after commencement you once more walk to the developers office and you find that they have not started yet but claim their machines are all setup. You are told that there was sufficient slack allowed in the schedule and there is still so much more time to get work done. You are a bit apprehensive but you comfort yourself, after all this guys are professionals, surely they must be.

5 months later there is now some progress and they call you to their office. Eagerly you wait as they open up the first page of your brand new web app which looks freaking fantastic! You love the landing page, the color scheme is amazing, truly reflects the essence of your business. You try to click the link to login and are promptly stopped from doing so. As it turns out the page you are looking at is the only thing that has been developed.

Our story ends here, you see it does not matter even if the developer somehow delivers the project in the three months remaining, the project is already failure. The obvious reason is that the product will not have taken the clients feedback into consideration. Even more insidious, the developer forgot a basic tenet of software engineering.

    Perception of slow development can affect your project as much as the reality of it.

You see, it is part of the developers job to provide their client with steady signs of progress.

So how could the developer have gone about this task? That is what this entry is all about.

Standardized requirements and checkoff

In a previous entry I talked about Investing in user stories. A side benefit of using user stories is that they easily avail themselves to be broken down into developer tasks.

Developer tasks are actionable items to be carried out by developers.

By breaking down the project into such tasks. Progress can be made visible as tasks are checked of and then entire user stories are marked as done.

Status meetings

Now I hate meetings as much as the next guy. But truth is that the most effective form of communication happens face to face. This meetings don’t have to be long, they just need to be regular.

Scrum practitioners have mastered the art. Their meetings are called daily standups and last a maximum of 15 minutes. All team members answer the three questions:

  1. What did you do yesterday
  2. What will you do today
  3. Are there any blockers

Status reports

Ok maybe the idea of regular meetings is too hard to swallow, what about regular reports? The basic idea is the same as meeting but now people submit their progress via email or chat.

This can be more convenient since a record exists and the reports can be done asynchronously.

Milestone reviews

As a developer, you should only write enough code for the client to review. At project onset, you can decide this review periods and set them as milestones.

Bonus points if you can tie compensation to this events.

By having clear milestones and reviews, the client is kept in the loop and their feedback is integrated on future iterations.

Walking around

Yes I know developers are professionals and don’t need someone watching over them. But this has nothing to do with the developers. By giving the client a chance to come to your office and basically walk around seeing your scrum board, burn charts, design diagrams etc. They get pleasant warm feelings about the progress of their project.

I hope it’s clear to everyone why its important for clients to have this feeling.

How do you keep your own clients in the loop? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail