Table of Contents
Nowadays most of the companies claim that they are Agile, it became kind of a standard. The majority of them also say that they build working software, but in reality each company understands it differently. And here is the problem! In Apiumhub we have done agile development for many companies in different industries and came to the conclusion that to be truly Agile we should do TDD & CI, focusing on working software. And when I say working software, I don’t see it only from functionality point of view, but from the technology point of view as well, taking into account performance, scalability and cost effectiveness.
Working software formula
As most of you already know, agile development is all about iterative and incremental evolution. Agile methodology helps software development teams in a changing environment focus on the rapid delivery of value and on building working software. Agile development is based on rapid feedback, continuous improvement, flexibility, and the delivery of results with high quality and working functionality. In software world, when we talk about Agile methodology, automatically, we talk about unit testing, test driven development and continuous integration.
For example, using TDD, software developers create unit tests when they program their code so that each one tests a small piece of software code to make sure that units perform as it is expected. Also, TDD allows teams to delete, add or edit functionalities in a fast and very effective way.
As in software development faults occur extremely often, TDD is really a must here in order to avoid finding bugs in the build stage, but discover them at the initial stage of the development.
In TDD, you begin by writing tests before coding new functionality. And you write the production code necessary to make the test pass, and only after that you refactor the code to make it more maintainable. This method guaranties immediate feedback after changes are made, so in other words it makes it very easy and very fast to find new errors. This immediate feedback allows software developers to fix the defects much faster compared to other methods where code is tested days after implementation. TDD shows you if the code does what it is expected to do in real time. Basically, it allows you to save time and money as well as fight for the first mover advantage, because you launch high quality functionalities faster, which is really key to success in this rapidly developing world of technology. What is more, test driven development implementation is more likely to match the product owners vision when we are talking about user stories. Tests are easily developed from the acceptance criteria. TDD guarantees that the final version will meet the needs of product owner, which is precious in software development world. Also, what we really like in Apiumhub, is that TDD prevents having unwanted design or components in the product. It defines the exact set of required features. It makes it very easy to find redundant code, detect and eliminate unnecessary development tasks.
TDD really goes together with agile and with working software, it simplifies and speed up the process of developing working software, making it possible to launch a new scalable product as fast as possible with a solid and working MVP.
As for Continuous integration, we think it is a crucial part in agile software development. And it helps developers to build working software, because it organizes development into functional user stories, which are put into sprints. Each time, when software developers make new addition to their code, it’s test can be added to the suite of tests that are run when they build the integrated work. It allows them to make sure that new additions don’t break the functioning work of existing elements, and developers whose code does in fact “break the build” can be notified quickly. Also, I should say that we are big fans of Martin Fowler, we always read his blog and strongly support his point of view. He says that continuous integration is a software development practice that requires team members to integrate code into a shared repository frequently. The idea is that every person integrates at least daily, which leads to multiple integrations each day. Moreover, normally several people or even multiple teams work on the same project and continuous integration helps to prevent integration problems. These integrations are verified by an automated build that runs regression tests to detect integration errors as quickly as possible. The CI rule states that programmers never leave anything unintegrated at the end of the day. So, teams always know what they team members work on, how they did it, and they are sure that their code works and is integrated correctly and even if something doesn’t integrate or something doesn’t work, it’s easy and quickly to solve. Integrating code frequently leads to reduced risk of failure, reduced risk of overspending money on redoing work. Normally, once team members have implemented continuous integration, they never switch back, they stick to CI, because they find that it leads to fewer integration issues and enables development of working software more rapidly.
In a way to production, there are a lot of struggles and issues, always. But what we think, is a good way to measure progress is “Working software”. What do I mean by that? Working software is a tested software that delivers value to the end-user, value that works well, maybe even better than expected, but never worse! In other words, working software is a software which is fully integrated, tested, and ready to be shipped to customers or deployed into production. The only thing that counts is completed, fully functional pieces of the wanted product – working software.
Working software rules
To build working software it assumes following several rules, for example:
- If you are not getting everything you planned to finish? Then take on less, but do it good. Don’t try to develop all the functionalities, when half of them won’t work as expected. Do half, but do it right.
- If you see defects in your code, test it sooner and better.
- If your code is hard to work with, then refactor it as you go.
- If it is hard to integrate, then integrate smaller pieces more frequently.
- If you deliver your work to your customers and they don’t like it, then talk with them more before you start and during the process.
So, what may help you build working software? Your commitment & focus, putting quality into your work, active user involvement, good understanding of definition of done, sprints of 2 weeks, TDD, CI, acceptance tests and thinking about performance, scalability and cost reduction.
And ones you have built working software, make sure you go live right.
Go live strategy & checklist
- Make sure all unit & functional tests are green. If they do not pass the artifact is not even built.
- Once we have the artifact, ensure that all the acceptance criterias are met. Here it is very important to consider user story format.
- If all the acceptance criterias are OK, test the main functionalities of the app manually.
- The logical user flows are covered by automatic functional tests but there is always a room to some visual mistakes or errors, so the manual QA is inevitable.
If you are interested in how other CTOs go live, check this article out! Where 10+ startup tech leaders reveal how they prioritise software development.
I hope this article was useful for you! In Apiumhub, we truly believe that working software is key, it is the right way to work on the software project.
