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:
- Actual costs to build a veranda (№1)
- Costs to fix something that we have accidentally broken throughout the work process (№2)
- 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
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.
Responsibility between the Client and the Development Company
For an outsourced software development company, communication and workflow organization are the keys to a successful and effective collaboration. In addition to communication and organization, there is also an issue of shared responsibility and trust.
The Always Important Human Factors in Development
The science of human factors makes a compelling case for becoming integral in the development of almost any product or service. It moves the conversation from what you envisage will happen in theory to what will actually happen in practice due to human traits, quirks, limitations and general characteristics.
Soft Skills for Developers: Why Do they Matter and Which Ones are the most Important?
Technical and soft skills for developers go together like peanut butter and jelly. Though the employer will first be looking at the tech background and the experience with specific tools, soft skills determine whether the person will stay in the team for a long time.
01 / 04