Posts

It was the summer of 2001, when I walked into the office of a small student recruitment agency. They were in the business of finding exceptionally talented students for part-time jobs working in the IT industry.

For students, it meant bringing their knowledge into practice, while for the companies it was both an opportunity to get work done at a low price, as well as a recruitment channel. But I was there for a different reason.

The breakdown

The recruitment agency had asked me to custom build their website. Nowadays you wouldn’t build your own CMS, but in the early days of the internet, this was more common. So, there I was, ready to talk requirements on a hot summer day, in the souterrain of a canal house in Amsterdam.

Across the table from me was one of the owners of the agency. They explained in detail what the goal of the site was, which functionality he wanted and how things should look. We made a few changes to the sketches he had already made, and I was good to go.

To give an accurate quote, I broke down the work into smaller pieces. Designing the database, writing code to retrieve and store data, and code to handle the functionality. Finally, writing HTML and CSS to make sure the site would look nice in all browsers.

I then estimated each piece separately, making sure no single estimation was higher than 1 day of work. If that was the case, I would break it down into smaller pieces. Grand total: about 10 days.

Doing the work

With the estimation and the work in hand, I started coding. I already had considerable experience at the time, since I was used to doing a lot of similar coding, so I was confident in my estimations. As I was coding, I continuously checked how much time I had for each piece. This forced me to work quickly and effectively.

After I had finished coding and testing I had spent exactly 4 hours less than I had estimated. The site was now ready to be tested by the agency.

Big surprise

When I entered the office of the recruitment agency again, the owner was already there. He had tested the site and, apart from a few minor pointers, it was completely to his liking. Then he told me that he didn’t expect me to finish this quickly. He had actually anticipated the project to take 1.5 to 2 times longer!

I was perplexed, I had given him a very detailed quote, which he’d accepted and he expected me to take longer than I told him? What did he know about how fast I can work!? So I decided to ask him why he thought I would take so much longer.

In his experience, he had never had a project done in the estimated time. It usually took at least 1.5 times longer than projected, which is why he had already factored in this number. He then told me that he did the same towards clients. A student would give him a quote, he would double it, and present that to his customer.

It all seemed strange to me, these were people that were good at what they did, had some experience with it, yet couldn’t estimate a simple project correctly… I didn’t give it much more thought then; my customer was happy and I was happy having done a good job.

Estimating is key

Years later, I encountered similar situations in software projects where I wasn’t the one making the quote. It only then occurred to me that there was something that most quotes have in common, which leads to the estimation being incorrect.

Where I had broken down all my work into neat little pieces that were easy to estimate, this is not always possible. There are several reasons why this is the case. The most common one is that not all requirements are known when the quote is requested, making it very hard to give an accurate quote. Estimating for uncertainty is something that is bound to be inaccurate.

Another reason is that usually the work isn’t broken down into smaller pieces that are each estimated separately. Rather, the project is estimated as a whole, or in big chunks of work. Humans are notoriously bad at estimating, which means that the larger the chunks are, the bigger the difference between the quote and the actual effort will be.

The final reason is the most important one. You have requested a quote. But you have not requested a single quote. Usually, you request multiple quotes. And the most important decision factor is price. This means that companies will often leverage the fact they don’t know all requirements. They will estimate everything that is known, but leave all other points open. This will of course be ironclad in the fine print.

Getting good quotes

To get a good quote, it is very important to have someone who can judge the details of the quote. And I don’t mean the financials, that’s the easy part. It’s about the technical details. You will need to involve one of your team members who can identify what has been left out, even if it’s not specified.

The most overlooked aspects are usually security and testing. Testing should simply be part of the quote, as well as fixing any issues that emerge from testing. Security is a very costly aspect if not done right. And getting it right, is hard. So, make sure to get a security expert involved in all of your software projects, as early as possible.

And the last thing you can do, is to ask for a fixed price for the entire project. This can identify the points of the quote that have intentionally be left open. Because when the company knows they cannot charge you more if it costs more time, it is suddenly in their best interest (instead of yours) to get the quote right.

“This software product already does 90% of what we need.” If only I got a cent every time I have heard this. It is the most ridiculous argument there is for standard software versus custom built software. When companies or teams select software, it is a common mistake to look at the percentage of functionality covered. Doesn’t a 90% coverage mean it’s just a small step to get exactly what you want!?

Adding a floor

Consider a high rise. 50 floors of exquisite architecture, exactly in the right location. And it’s super affordable. If only it had 2 extra floors…

The solution might be simple. If you need 2 floors added on top, that might be a viable option. Perhaps the elevator won’t reach them, but it wouldn’t be extremely expensive to do.

It’s a slightly different story when you need a double basement underneath the building. It’s still possible, but far more expensive.

The ultimate case however, is if you absolutely need to add two floors at the bottom or in the middle of the building. I am sure it can be done somehow, but I bet it’s cheaper to build a new building.

Adding a software floor

All three cases with the building add 10%, but it seems obvious that they are not equal. In software however, we somehow assume they are equal.

So whenever you consider ‘adding a floor’ to standard software, make sure you fully understand exactly what the impact is. No matter how configurable the software is, how many happy customers there are that ‘do things in the same way for 90%’ – if you try to add the wrong floor, it’s going to cost you.

In 2008, I brought my car to the shop for a periodic check-up, because it had a problem. Sadly, the check-up showed my car was in desperate need of repairs. The mechanics told me that it was probably not worth the cost.

It was a very, very old car and I had seen this coming for a while. Still, a mechanic telling me I’d best buy a new car, wasn’t really what I had in mind when I brought it in.

Adhering to a strict schedule

My first car was an old second-hand one. To be honest, I hadn’t been too strict with the maintenance windows. So, when I had to suddenly replace it, I vowed that when I would buy a new car I’d always take it to the shop on time, to make sure it was always in perfect condition.

The upside of taking your car to the shop on a regular schedule is that it is indeed always in great condition. The downside however: you get told by mechanics that something needs to be changed and you basically don’t know whether it is strictly necessary.

So, you have them replace it. When it comes down to it, this means spending a lot of money on things that do not seem broken.

Maintenance on custom built software

Any application that is custom built, or has a custom built component, will require maintenance. The simple fact of the matter is that the world around that application or component changes, which may require the application or component to change in return.

This is actually quite similar to owning a car. You buy the car, and because you use it, it requires maintenance. Just like software requires maintenance, due to the world in which it is used changes.

You bring your car to the shop for a check-up, the same way your software requires some maintenance every once in a while too. All to keep things running smoothly. For custom-built software however, most companies do not perform maintenance as often as is required.

Instead, they prefer the method to use it for as long as humanly possible, after which the whole thing needs to be replaced. Much sooner, though perhaps at slightly lower cost, than performing periodic maintenance.

Knowledge gap

If it isn’t broken, don’t fix it. It seems like sound advice. But if you don’t, it means using everything until it is absolutely worn down and replacement becomes paramount.

There is a huge gap between following every advice from a car mechanic and only replacing parts when they’re totally worn out.

This gap is a knowledge gap. If you’re like me, you don’t know everything about the car you own. This puts me in a disadvantaged position whenever a mechanic tells me something needs maintenance or replacement, especially if it isn’t causing a noticeable problem.

If I trust the mechanic, I’ll let them replace it. If I don’t, it is usually about time to bring my car in to another shop.

Bringing your software to another shop

In the past, I have switched shops for car maintenance a few times. This is fairly simple, since cars are a common thing and there are many shops that can service my needs. If I am unsatisfied, I simply take my business to a competitor.

And for software it’s pretty much the same deal, right? Software is very common. There are many companies that can build software and maintain it. So if I am unsatisfied, I can just switch to a competitor, just like I did with the car. Or can I?

The problem is that software, especially when it’s custom built, requires an understanding of how it works. Most applications also communicate with other applications, and are implemented to support a business process.

This makes understanding ‘how it works’ a lot harder. So, unlike bringing your car to another shop, bringing your software to another ‘shop’ would cost a lot of time and money.

The new shop would first need to get a good understanding of your business process, the other applications that the software communicates with and then understand the code of the application itself.

No leverage

Inevitably, you are left with without any leverage. Because if you cannot bring your software to another company easily, you only really have 3 options:

1)      Don’t perform any maintenance at all
2)      Just accept anything that your supplier tells you should be done
3)      Insource maintenance of the application

We believe that this status-quo should change. Not performing maintenance means losing innovative strength, since adapting software to changing processes or markets is no longer an option.

Accepting anything that your supplier sells you will cost too much money for what you are getting in return. And lastly, insourcing maintenance is extremely costly, if not impossible, due to the shortage of IT professionals.

Freedom

Triggre strives to give companies back their freedom when it comes to implementing and maintaining software. Just having the option to make software yourself (without IT specialists) is a game changer, which makes you far less dependent on external companies – including us.

It is hardly a big secret that it is hard to find good developers. And that salaries for these developers have steadily been increasing over the past years. Faster than other salaries, as well. This is just how the market works, so what’s the big deal about it?

The big shortage

In our whitepaper about the IT Shortage we give a lot of background on the ever growing shortage of developers and solutions. But let’s focus on just the main issue at hand: the shortage itself. Most people I talk to only experience developer salaries going up and the fact that it is hard to find developers on the labor market. A very interesting number however, is the actual absolute shortage.

Last year the number of software engineering students graduating in the US was 50.000. Universities have been estimated to be able to educate 8 times that amount by 2020, meaning 400.000 software engineering students graduate that year. So far, so good.

The problem becomes apparent when we look at the amount of job openings in the labor market for software engineers. In 2016 the number of job openings was 223.000 in the US. Gartner estimates that this number will grow up to 1.400.000 in 2020. In other words, last year 23% of job openings could be covered by graduate students, in 2020 still only 28% of job openings can be covered by graduate students.

That’s hardly an improvement. In the chart below I have plotted these numbers so you can easily see the problem.

Chart

Because the most detailed data was available for the US, I have used that data. However, similar numbers are found in almost every other developed country around the world.

The source of the demand

The increase in demand for software developers can be attributed to growth in many sectors that require software. The biggest growth is in the demand for custom software. In 2011 the world-wide demand for custom software was USD 43 billion. This grew with 33% per year to a whopping USD 136 billion in 2015.

This growth is expected to continue due to globalization forcing ever more companies to distinguish themselves from ever more competitors. One way to do this, is with custom built software that implements their unique business processes.

Below is a chart that shows this growth from 2011 through 2015.

Chart

Stagnating innovation

The combination of higher demand versus ever increasing developer salaries is a toxic one. Ultimately it means that only the richest of companies can afford to hire enough developers to keep their competitors at bay.

These front-runners can easily expand their lead, leading to more revenue. This revenue can then be used to pay developers even more, making sure they don’t go to the competitor. Companies that cannot cope with the increases in developer costs, will be sentenced to mere mediocrity.