Your dev team screwed you? Here is why.

So, it's already late night, you have been working hand by hand with this development team to publish your app before yesterday. You have an important meeting coming up tomorrow morning where you wanted to impress some stakeholders and investors by showing them your newly developed app concept, and all you got is one last minute power point presentation with a couple of screenshots and information about the app's idea. Three months have gone by and your app is no where near. Maybe it's time to quit?

Ok , they screwed me over, now what?

Hey! Stop shouting at me! ok? I'm only here to help you so cut the crap and stop whining about it. I know it's not gonna help , and I only trying to be helpful here, but if it got this bad without you noticing, it  probably is your fault only. This the first part of a series of blog posts that I want to introduce to you about problems that might arise from developing a sw project and how to deal with them.

Calm down, I fear there's very little you can do by tomorrow morning, so what I'd like to go through with you, my dear reader, is to pinpoint the main reasons why so many apps have so many problems in development. Maybe you can see a similar situation building problems up with your own idea, but I'm not sure, we have yet to meet so...

Ok, first things first , you are not alone in this suffering. Software development doesn't always go right. In fact, statistics show that most software projects actually end up going WRONG (only 29% of them succeed).

Maybe you chose the wrong development partner or team. Maybe you set up unrealistic and / or risky goals for development. Maybe your developer set up wrong expectations and to top it all off, you had poor understanding of how software development Works (Don't look at me like that! I'm not implying anything, but if you got here something must have gone horribly wrong).

First things first.

Take your time to figure out what went wrong, don't just blame it all on the developer. In my software experience, delays in production are normally caused by the client's side or team not specifying correctly what needed to be done, or client changing the requirements in the middle of the development because they found an idea that suited them better.

According to the Standish Group software development report in 2015 - which evaluated over 50.000 development projects from different countries accross the globe - the scary reality of software development (and being a Software developer I realize i might just be shooting myself in my feet by saying this) is that the average cost overrun was 189% of the original cost estimate, where as time was overrun by 222%. This means that if your project's estimated completion time was of 5 months, in reality if would be handed to you in 11 months - which let me be very clear by our standards is INSANE.

How these delays happen is due to many factors. In my experience both client and developer can have the blame on this. On one hand, clients tend to neglect the importance of some information that must be given to the development team in charge of their app. Project specifications are not always properly set, so the developer team has to ask many questions to the client as to how does the client want its own app developed. 

On the other hand, dev teams are oftenly saturated with hard work. App and web development are in high demand these days, so it's very common for a development team to have a lot of work in their plate and sometimes make promises that they can't deliver.

"Promising to much can be just as cruel as caring too little" - William J Clinton

My first advice here would be to be very sceptical about what a software development team tells you about dates for project completions. Mistakes will be made, we are humans and as such we make wrong estimations and mistakes. Nobody is trying to steal your money here (well... maybe, but you would have definately noticed that a long time ago). If your team tells you they will have their work finished at some specific date, try to have a contingency date. Depending on how professionally they work I would estimate about an extra 15% time margin just in case.

Three important factors in software development

iThe most important factors I've seen in software development so far can be resumed in three simple key points. You can only pick two of them at the same time , and if anyone tells you that you can have all three at the same time he is lying to you (consider running away from them)

Some things to be aware of.

Beware of hidden development costs. The "Fixed price" you see in a contract is sometimes only the beginning. It is very easy to sign a contract that has a fixed price, a fixed time and all of the development requirements properly defined. However, trying to arrange quality, speed and price at the same time is generally a big lie.  This is a very common practice in software engineering by developers in order to over-promise to clients that do not understand about software development, in order to win work upfront.

This is a very commonly employed tactic to earn more money in future change requests or to simply grab the client's attention only for him to bid first (even though delivering is not scheduled in time.

Another suggestion I can give you is to offer bonuses - something very similar to what I consider tipping - if the development team finishes it work accordingly and in time.

These things are most problematic when trying to foresee this with hindsight. 

  • Maybe you want to make a critical change to your product that will make your product better but you have to change a big chunk of functionalities that are in development in order for them to work.
  • Maybe a competitor launches the exact same functionality when you're midway through development even though you've signed a fixed scope contract, which will cost extra money for change requests. 
  • Maybe you are using a 3rd party API that simply revokes access to that data, meaning that what you wanted to be developed can no longer be done, and you need it to approach that problem differently.

    You shouldn't operate under the assumption that you can think and plan everything ahead of time and foresee every single problem that will arise when developing your own app. Instead, I suggest you embrace these changes and be constantly looking to improve your product along the way under the right development model.

    Another bad attitude I've noticed when clients talk about software is how clients think software development works. Developing software is not like buying a car but more like building a house.

    Cars are not custom built, they are products, developed with mass production and made to be equal to one and other. You buy one and you can feel how it works and how it feels. Two same vehicules will feel exactly the same when they are on the road.

    Houses, on the other side, are not simple products that you can find on the shelf of your local superstore and just grab. Each one of us has a different opinion of how the house should look like, giving different importance as to what the most important feature of the house is. What skills do you want your contractors to have? How do you want it built?

    It's not only about paying the project and signing a contract. It needs to be tailored to each individual. Developing software is a lot like building a house. When you start building it, problems might arise (was this column in the original specification? It's not supposed to go there but if we demolish it the whole thing might fall down!!). And of course when you are building a house, you'd (normally) step by the house being built a couple of days a week to check how the builders are doing. Why not do the same with software development?

    Software development can be a bit unpredictable. It has many variables and "unkowns" when the project starts, and these keep unfolding as the project continues. It is your duty as the future owner of the software to unveil all of this unknown variables and let your development team know what to do about them. You might have the best crew in the ship, but without the captain properly steering the wheel the ship will probably get lost.  And in software development, never forget that you are the captain of your own ship, so if you don't know how to , make sure you have someone inside your boat that knows about navigation.

    Be the first to comment

    Our reader's favorite picks

    Subscribe to our newsletter

    Let us send you spam from time to time. Yes, it is a bit of Spam, but interesting Spam, supreme quality spam to be honest!

    Email *