What I like about software development is the diversity of subjects I have the opportunity to explore. What I like even more, is that my opinion and the way I see things constantly changes.Strange as it may seems, in my domain (embedded, C/C++ based, telecom industry) Continuous Integration is not a familiar term or practice.
From my limited experience in the field, practices and tools that support CI for Embedded C/C++ programming are rare.
For many (in our domain), the idea of every check-in to a release branch becoming a deliverable build is insane.
Designing and coding for a few weeks, followed by a few weeks of QA tests is very common. There is a clear separation between the development stage and the validation one, starting from personnel physical location, through the purpose of the team and the measurement of its productivity & effectiveness.
Project managers support the separation by bridging gaps and scheduling work between the DEV, QA and other groups. The legacy attempt to plan everything in advance, bring PM/s to schedule delivery of builds and their content early on, even though practice teach us that rarely a team can keep up with the original planning. The practice is repeated and optimized with time by building more and more graphs, excels and tools to make the estimations and plans more accurate.
By the nature of this planning, the development team will look for the most suitable build rate delivery, taking into account the overhead of aggregating all changes (of all components) in a build, testing each, preparing documentations, etc.
Coming back to the purpose of this post, here is a proposed change from the ground up: Embedded or not, SW is SW, if CI works so well in the industry, embrace it and try it out.
Trying to depict some advantages of frequent build delivery, I came up with these few points:
- Response time between detecting and resolving bugs is shorten extensively:
- From the tester perspective, he may receive a build immediately after the programmer checked-in the fix. This keeps the tester in the same scope (subject, setup, etc...) which should reduce the validation time.
- From the programmer perspective, the feedback on his work is closer to the actual change and therefore easier and faster to resolve issues.
- As a nice side effect, check-in quality (to release branches) increases due to the simple fact that it is also a delivery. Breaking builds is no longer a private failure that affects the productivity of the college programmers, it has a larger effect that is not acceptable and therefore it must be resolved from the roots.
- Interaction between DEV & QA increases, they communicate more and allow testers be involved more in the development process and affect it.
- Opens up areas to improve the process at low levels, from automation to programming practices which shorten the feedback loop and increases quality.
So lets try it out: Build without restraints, encourage testers to use the builds and validate the changes.
Obviously, nothing is for free, and there are points which need treatment before proceeding in this path:
- Version format needs to support a large number of builds.
- CI tools need to be integrated, allowing automated build creation, making build creation "cheap".
- Introduce automated Unit Tests and Integration Tests to increase/assure quality and reduce the overhead of creating builds (in relation to tests).
Feedback and other ideas are welcome, especially if you do not agree. :)
I personaly thinks It makes sense to work like it.
ReplyDeleteBUT I think that it is easy to "write" on it but hard to implement.
You didn't cover the company/organization weight, influence on the success of this idea...
You raised some points that need to be treated before starting, which also cost time and money.
When you're working in an "old fashion way" as you described, the structure of the "development unit" and the "development life cycle" should be adjust to the new concept in every aspects, and in order to make it happen and to gain from it the most... we must change our mind set, which means all organization should embrace this concept.
And another thing "..rain down builds and deliver without restraints." it is very hard to accomplish if you are not there, but we can benefit alot also from the preparations...
I personaly think that we'll need restraints, also if we'll reach the point we will work like you described... it can take time you can rely on the process and on the quality...
congratulation on your new blog :-)
Good luck!
Thank you for all the points.
ReplyDeleteThe intention of the post was to raise the topic for discussion, at least as a first step, beyond that it may be considered a bonus.
It seems indeed challenging to try and practice such a development cycle and as someone already pointed out, failure is just around the corner. Nevertheless, as you mentioned, even if a team fails, the learning phase and experience gained during the process is valuable and can push productivity up.
It also breaks norms, making things a bit more fun (for some I guess).
One last point: If I look at changes as bottom-up, starting from individuals and small teams, organisation level support is not a must, at least if the changes can be broken up and contained.