Nearly every embedded software team I encounter is interested in becoming more agile. Adopting Agile practices can dramatically improve how agile a team is. Businesses and developers all want to be able to deliver faster. We don’t want the headache of late and buggy code, yet we often just accept that is what life is in the software world; However, it doesn’t have to be that way. In this post, we will explore five tips for becoming more Agile.
Tip #1 – Ditch Code Review, Adopt Pair Programming
There is a big push within the software industry to do more code reviews. Studies have shown that code reviews are the most effective way to identify and remove bugs. However, there are a lot of problems that are encountered with code reviews! First, developers don’t want to do them! They are viewed as time-consuming, boring, and generally get in the way of getting real work done. I’ve encountered teams where they know they should do more code reviews, but the idea of reviewing 400 lines of code per hour (the industry recommended pace), is a snail’s pace when there are 10’s or 100s of thousands of lines of code that need to be reviewed.
A simple tip to make software development more agile is to ditch most code reviews and adopt pair programming instead. When two developers are working together to write the code, they will be performing a code review while the code is being written. The result is that mistakes and issues are often caught immediately, removing the need for boring team code reviews. Larger code reviews can be saved for mission-critical code, saving the software teams many headaches, and helping to make them more productive.
Note: This is a controversial idea. Studies show that you should be performing code reviews to minimize bugs, in fact, they are the most effective way. However, I come across a lot of teams that do too little to be effective, and if you’re going to do little to nothing, then you’ll benefit from pair programming.
Tip #2 – Automate Testing
If you took a moment to examine the many different Agile practices that have been defined over the years, you’ll notice that a critical one is testing. Software developers are notoriously bad at testing, and therefore many disciplines focus on testing. For example, if you look at Ron Jeffries Circle of Life diagram, shown below, you’ll find that testing is found in every layer (TDD, CI, Customer Tests). To become more Agile, developers need to adopt better testing practices and make sure that they are automated.
Image Source: https://ronjeffries.com/xprog/what-is-extreme-programming/circles.jpg
Several years ago, I had a simple project that a customer needed to be done. From their description, we decided that having an automated test harness would be overkill. A few simple manual test cases were all that was really needed. A year later, and with all the scope creep that went with it, I swore I’ll never start a project again with an automated test harness. In the beginning, it may seem overkill, but the time and pain it can save in the long run are well worth it!
Tip #3 – Shorten your cycles
One key to becoming a more agile software developer is to shorten your cycles. The idea is probably most obviously seen in the push for Continuous Integration and Continuous Deployment. Developers can break their development into smaller and smaller pieces so that they are able to commit small incremental improvements and features to the software codebase.
I often see embedded developers who will take long periods of time to complete their cycle. They’ll work on several different things at once and commit code that is broken and doesn’t work. In many cases, features can be broken up into smaller, functional features. Those smaller features can then be tested and integrated with an ever-smaller timeframe.
Tip #4 – Don’t become Tool heavy
When teams agree that they will start to use Agile techniques, they often get excited and jump into finding a tool to help them manage their “Agileness”. Unfortunately, when this happens, there is a temptation to dive into a tool and try to maximize its use. Instead of the team developing their processes, the tools they choose force them into a process. That process may fit the team’s needs, or it may not.
Many Agile tools available today can be used by small to large teams, but the tool producer may benefit more from larger teams over smaller teams (think licensing models). When you first start to become more agile, don’t give in to the temptation to become tied to a tool or get to a point where you spend more time in a tool trying to manage things. The tools you use should make you faster and more effective, not tie you done and make it more difficult to work.
Tip #5 – Divide and Conquer
Sometimes, when a team wants to adopt Agile practices and modernize their software development processes, they encounter some developer pushback. Some developers won’t see the benefit of adopting certain techniques or are at a point in their career where they don’t want to learn new tricks. When this situation arises, I’ve found that it can be more productive to divide the team. (It can be tempting to just fire non-compliant team members, but this is rarely effective)
The first part of the team becomes the maintenance heroes. These team members focus on using established processes and techniques to maintain and improve existing code and product lines. They stay behind to fight the battles of poorly architected software, spaghetti code, and so forth. The second part of the team becomes the future platforms team. This team is provided a blank slate to adopt and leverage more agile techniques and processes. The team members are often excited and interested in learning and using new techniques to become more effective software developers.
Many teams today do leverage Agile software practices; however, I’ve found that many embedded software teams struggle with it. In today’s post, we’ve explored a few low-hanging fruits that developers and teams can reach for to become more agile. Take a few moments to carefully consider these tips and how you can apply them to your own software practices.
Pair programming is not a replacement for code review. This is like saying if two people wrote a book or article together, there would be no need to have an editor. Having jointly written multiple pieces, I can say from an experience that an editor still finds plenty of errors and ways to improve.
Just because two (or more) people participated in the writing of the code doesn’t mean that they wrote perfect code. Asynchronously reviewing code, especially with someone who is detached from the code, exposes flaws and improvement opportunities. Even with a self-review, there is a benefit of having space between when you wrote it and when you reviewed: you become detached yourself, and can see the blemishes that you might not have noticed the first time.
I agree, but given that so many companies refuse and don’t have time for code reviews, pair programming can be an interesting “better than nothing” substitute that has many advantages. The goal is never to write perfect code, it’s to write good enough code. No matter how many times you go through something, someone will always have feedback and ways to make it better. At some point, the return on investment diminishes and everyone is just wasting their time.
I agree that pair programming is better than nothing, but the article is arguing for ditching code reviews and replacing them with pair programming.
As for the words “perfect code”, I did not argue for perfectionism. Phrased with more words: while two heads are better than one, two heads are still subject to cognitive limits and biases that lead to the potential introduction of defects which cannot be identified by the authors (especially at the time of writing). These are more easily identified during a detached review.
Ah yes. (I should reread and read more carefully how I respond and what I write). Thanks for calling me out on this one. 🙂
I’ve tried to add a little note on where / and why I would recommend that. I completely agree with your statements. Code reviews are preferred, the headline there was designed to be controversial, but speak to the audience in very small teams where the code reviews are ineffective and they would benefit from code reviews more.
Jacob I am almost always in agreement with what you say but I think you are way off with the pair programming thing.
If a team is not doing code reviews then *that* is the problem, fix that, don’t say do something else that is not as good.
From a dollars perspective it is going to cost less to have a couple of people do reviews than two people writing the whole thing. Don’t have time for reviews, but you have time to put two people on every issue? Makes no sense.
In my experience pair programming is not effective at all. Especially in this remote working environment. The times I have pair programmed reduced my productivity by a huge amount and the code was bad. I am juggling 7 trade-offs in my mind while I code this thing and now I have to express that to another (probably junior) engineer? There is a huge impedance miss-match between being in the creative zone and the collaborative zone.
The code review mind-set is much different than the code creation mind-set. A great editor may not be a great writer and almost certainly vice-versa. They are two different skills.
Interesting. I’ve generally had beneficial, productive pair programming experiences. Even remotely, we set up Visual Studio Code so we can both view and edit, and then get Zoom going so we can talk and collaborate. Usually, the “primary developer” has laid out the core problem to solve, tests to develop, etc.
Jacob it’s great to read your post! Thanks!
Regarding #3 Shorten your cycle: we’re currently switching to agile technics .
And it’s not so easy to shorten the cycles. Some developers who spend decades on developing software cant see this small steps because they never trained or learned this.
Refactoring with small steps was never required .
How long will it take as a team – from your experience – to successfully apply this ?
Ah yes. It can definitely be a challenge. It can range quite dramatically depending on the personality of your team members, their experience, willingness to adapt, etc. I’d hate to take a stab at it without knowing the details. I do wish you luck in quickly adapting to the shorter cycles!