How we help development teams to spend less time on fixing things that have already been done.

We don’t always develop the projects from scratch because at times our clients ask us to solve more simple tasks – for example, develop a new functional in existing software project.

In order to sound clear for non-technical person we shall use an analogy: imagine that we have to build a veranda for a house.

It is obvious that before any work we have to estimate how much time it will take us, what tools and materials we need and how much it will cost.

At DashBouquet we have already built quite an amount of these “verandas” so now we divide all costs into three groups:

1. Actual costs to build a veranda (№1)
2. Costs to fix something that we have accidentally broken throughout the work process (№2)
3. Costs for something we did not intend to do at first but what would be nice to get done  

Second group usually brings the biggest amount of concerns. Neither tech, nor non-tech people get it. Besides, it does not even make sense at first. As if we’ve been building a veranda and suddenly ask to change the lightbulbs in the sauna.

But sometimes you don’t see these issues and this is why professionals aka QA should perform daily checks. If we get back to our analogy, QAs will be checking the walls, making sure plan requirements are met, turn the lights on and off and make sure veranda is warm.

We started to think on whether we could change that because the given costs are not essential and seem as lack of professionalism to our clients.

What can we do? We decided to use good old concept of functional programming called pure functions.

And what are pure functions? These are the functions that cannot affect the result of execution of other functions and that give same result under the same parameters.

This is obvious for mathematicians but doesn’t make sense for the programmers If we add up 2 and 2, we will get 4 in any case, on any planet, during any time era. But think about a situation when we calculate the ticket cost and take notes in the journal. Sooner or later, any person can make a mistake which will be difficult to find.

How do we use it? We introduced Purity Management, according to which we:

• Aim to bring the amount of pure functions in the program to 100%
• Carry out all logics into pure functions
• 100% of logics is covered by unit tests

We use JavaScript and React in the majority of our projects which makes our experiments safe and, most importantly, up-to-date with modern development tendencies.

Before getting to work we always do preliminary estimation of how long it will take us, as to our opinion. The precision of these estimations is an important part of the process as it affects the expectations from our managers and clients.

Our experiment has been going on for only half a year, but preliminary analysis shows significant improvement in our estimation precision (right now the median line lies along the border of 27% meaning more than 50% of estimations deviate not more than 27%). It may not sound very valid, however, it is few times more than what we had last year. In 2017 we plan to collect more precise data and share our findings with you in our blog.