Why fixed bid for programming gigs is the future.

Let’s stop doing agile and start building cathedrals.

TL;DR : with functional programming (and specifically elm), it’s easier than ever to evaluate how much time it’ll take to implement an application.

When I started my programmer career 12 years ago, I was doing PHP, and I hated project managers who were selling things we were developing. They were doing budget estimations based on the principle that 1 + 1 = 2, which, in dynamic and loosely typed programmation is basically false.

So I fought for years to stop estimating altogether, and started my own consultancy to be honest with my own clients : I would do agile development. Which means : no deadlines, no time estimations, 2 week sprints. And it worked, and I had some success doing it. I did better than a lot of people who where still selling things they couldn’t achieve. Beautiful packages of thousands of Euros, to create something they would never do on time or on budget.

And then came elm. And it changed everything. Let me explain how.

In a statically typed pure language like elm, you are writing pure functions which are taking parameters and are returning some result based on these parameters. You can view pure functions as perfect tubes where water doesn’t leak.

So imagine you have 1 pure function to implement, you know how much time it’ll take (or you can have an idea). You look at the parameters, you look at their types, you look at the result type. It’s a lot easier to guess how long it’ll take to program it.

And then let’s take 10 pure functions. They don’t interact with each other, they don’t have anything in common. The time it takes to implement them is the sum of the time it takes to program each one.

They aren’t intricate. They aren’t complex. They are simply functions.

We are really far from object oriented programming where you can have inheritance, classes, instances, modules, interfaces, scopes, global variables, etc.

When you add a function to a class, you are basically changing the behavior of the class, and all the internal attributes are magically updated. It means that you have to tale in consideration all the work you did before in order yo be sure you don’t mess with the other parts of the instance. And so, in object oriented programming, it’s almost impossible to estimate precisely, and accurately. So… almost nobody is doing it right.

But as I said before, estimating in a pure functional language is doable (it’s still a difficult task, but it’s doable). Imagine you have 30 screens and you know that a screen is taking 1 day to code. Then, you can estimate that it’ll take 30 days to create all the screens (taking in consideration all the complexity of the screens of course). And then you can work on the estimation of the transitions between all these screens (let’s say 30 other days), and the persistance of the data would be another 30 days (1 day for one screen did it). Let’s add 10 days of factory acceptance, and we are done with it. So 30 + 30 + 30 + 10 = 100.

But at the end of the day it’s just sums of estimations, nothing else. And we KNOW we won’t have crazy surprises in terms of complexity, so we can do as everybody does in every other industry than the software industry. We can do quotations. And stop doing agile and start designing cathedrals.

So for me, pure statically typed functional programming is a fantastic tool because it allows us to estimate wisely and precisely.

If you are intrigued, please join the mouvement and come to elmeurope.org. You won’t be disappointed.