During my time working as an engineer and software consultant I've been on some brilliant teams that were able to build incredible things in a very short amount of time. I've also been on teams that are, ehh, not so agile... Indeed, when I look up Google's definition for the word agile right now the first entry is, "able to move quickly and easily".
Although there are many flavors of agile development that all emphasize slightly different concerns, in this article I'd like to discuss three things that I consistently see done by the top software teams. I believe that any engineering team not already practicing these three things can get an immediate productivity boost by implementing them well.
So without further ado, let's get into it!
Although there are many flavors of agile development that all emphasize slightly different concerns, in this article I'd like to discuss three things that I consistently see done by the top software teams. I believe that any engineering team not already practicing these three things can get an immediate productivity boost by implementing them well.
So without further ado, let's get into it!
1. Leverage Automated Tests
Automated testing, when used correctly, can be an incredibly useful tool for moving faster without sacrificing accuracy. Unit tests and end-to-end tests are the yin and yang that complement each other that together give you the awareness of where your code is broken when they fail and the confidence that the code you're about to ship works when they pass.
Notice, though, that I say leverage automated tests. A few times I've seen test automation get out of control to be the point where they become unwieldy, too many tests checking the same things, etc. Don't let this happen to your team! Teach your team members to appreciate testing as a tool for them to leverage rather than a new goal of chasing green 100's on the code coverage reports.
Notice, though, that I say leverage automated tests. A few times I've seen test automation get out of control to be the point where they become unwieldy, too many tests checking the same things, etc. Don't let this happen to your team! Teach your team members to appreciate testing as a tool for them to leverage rather than a new goal of chasing green 100's on the code coverage reports.
More often though I see teams that naively write and ship code without any automated at all. Sure, this will work a few times in the beginning, but it quickly becomes unscalable, prone to human error, and turns the developers into manual testers. Ironically, throwing more people at the problem makes things worse, the software progresses way too slowly, and the project ultimately fails.
Meanwhile, the teams with unit tests all throughout the stack, with UI specs written in gherkin and executed against their front-ends using tools like Cypress.io, with backend endpoint tests run through something like Newman, with these tests all automatically run on a CI / CD server... these teams are able to stay lean while building intricate systems things that work flawlessly and are shipped frequently.
2. Work In Pairs
In my previous consulting project I was blessed with the opportunity to work on a team where everyone was on board with pair programming. Overall, it was a really great experience for me and showed me that pair programming gets the team to the end goal faster and easier than the "solo work" model.
Solo work is a cute derogatory term we invented for the traditional scrum "divy up the work and have everyone go their separate ways" methodology for developing software. The solo work model is just objectively slow, painful, and incredibly inefficient.
When one developer has to figure everything out on his or her own it can take a very long time before any working code gets written. Possibly the developer goes down a path that the team doesn't particularly like, but in this model the feedback isn't given until a week later when a pull request is opened, and then people start ripping it apart asking for it to be almost completely rewritten...
Solo work is a cute derogatory term we invented for the traditional scrum "divy up the work and have everyone go their separate ways" methodology for developing software. The solo work model is just objectively slow, painful, and incredibly inefficient.
When one developer has to figure everything out on his or her own it can take a very long time before any working code gets written. Possibly the developer goes down a path that the team doesn't particularly like, but in this model the feedback isn't given until a week later when a pull request is opened, and then people start ripping it apart asking for it to be almost completely rewritten...
On a different note, all of the engineers have vastly different experiences and expertise, and that knowledge gets shared across the engineers within the team exponentially more when pairing. Pairing is great because is shortens the feedback loop virtually to zero.
Indeed, pair programming is basically constant, continuous code review throughout the entire development of the code. Naive non-technical managers sometimes think that because the engineers can write half as many lines of code then in turn it will take twice as long to ship the feature.
Ha! To me, this is obviously complete foolishness since lines of code is hardly ever the bottleneck in software development- rather, the real cost of software is in the ongoing maintenance of the code- how quickly and easily it can be understood and updated with new features and patches.
Indeed, pair programming is basically constant, continuous code review throughout the entire development of the code. Naive non-technical managers sometimes think that because the engineers can write half as many lines of code then in turn it will take twice as long to ship the feature.
Ha! To me, this is obviously complete foolishness since lines of code is hardly ever the bottleneck in software development- rather, the real cost of software is in the ongoing maintenance of the code- how quickly and easily it can be understood and updated with new features and patches.
Pairing partners can keep each other honest by calling each other out when they are about to take shortcuts, practicing disciplined test-first TDD, and coming up with good names for things early on. When you work in pairs correctly there is often much less "re-work", much more high-fiving, and much higher quality code.
Some engineers are afraid to try pair programming at first, but I have found that even the most introverted coders can be more efficient and more helpful to the team when pairing.
Also, when everyone is pair programming I know they are truly engaged in the work and so as a manager and team lead I have no negative feelings when people take breaks or leave early because I know that they are working hard.
Some engineers are afraid to try pair programming at first, but I have found that even the most introverted coders can be more efficient and more helpful to the team when pairing.
Also, when everyone is pair programming I know they are truly engaged in the work and so as a manager and team lead I have no negative feelings when people take breaks or leave early because I know that they are working hard.
3. Keep It Simple
"There are many ways to skin a cat" is pretty disturbing idiom if you think about it literally, but the idea is that there are often many different ways to accomplish something.
In the great talk by Rich Hickey, "Simple Made Easy", he argues that as a programmer you should try to use tools that are simple and that will allow you to build simple solutions for your problems. All too often I see teams creating giant, monstrously complex systems when it's just unnecessary.
In the great talk by Rich Hickey, "Simple Made Easy", he argues that as a programmer you should try to use tools that are simple and that will allow you to build simple solutions for your problems. All too often I see teams creating giant, monstrously complex systems when it's just unnecessary.
-> Keep it simple on your web front-ends by using a modern framework that allows you to break things down into focused, declarative components.
-> Keep things simple in your infrastructure by hosting both your front-ends and back-ends with a serverless architecture.
-> Keep things simple in your database by choosing a db that represents and stores data in the same form that your front-ends want to consume it (these days, probably JSON).
Of course, simplicity is a pretty subjective topic as what's simple to one person may not seem so simple to another, but still- striving to keep your systems simple is a great rule of thumb.
-> Keep things simple in your infrastructure by hosting both your front-ends and back-ends with a serverless architecture.
-> Keep things simple in your database by choosing a db that represents and stores data in the same form that your front-ends want to consume it (these days, probably JSON).
Of course, simplicity is a pretty subjective topic as what's simple to one person may not seem so simple to another, but still- striving to keep your systems simple is a great rule of thumb.
One engineer may think JavaScript is the most simple because that's what actually runs on the NodeJS, and you don't need to understand all the "extra" rules of other compile-to-JS languages.
Another engineer might say TypeScript is the most simple because in code written with it you can clearly see the shape of the data that's being passed around between functions.
Then yet another engineer may argue that ClojureScript is the most simple because of its succinctness and expression-based nature.
Personally, I think they can all be correct and as with any subjective discussion it's all a matter of perspective. My advice would be to have opinions of your own but also stay open-minded, don't push people too far outside of their comfort zones, and just keep it simple.
Another engineer might say TypeScript is the most simple because in code written with it you can clearly see the shape of the data that's being passed around between functions.
Then yet another engineer may argue that ClojureScript is the most simple because of its succinctness and expression-based nature.
Personally, I think they can all be correct and as with any subjective discussion it's all a matter of perspective. My advice would be to have opinions of your own but also stay open-minded, don't push people too far outside of their comfort zones, and just keep it simple.
Are You Convinced Yet?
I'm very curious to hear how other software engineers feel about these tips. In practice, I see very few teams even attempting to utilize TDD and pair-programming, let alone do it at the highest level.
I have been fortunate enough to have worked with and learned from some incredibly talented engineers, and I truly believe that incorporating these three tips into your team's workflow will have a profound effect on the team's efficiency and the overall quality of the code.
If your team is struggling to adopt these practices, we can help! At Evaluates2 we provide group workshops, full-time on-site consultants, and impartial expert opinions to help you and your team(s) build better software, faster. Don't hesitate to contact us today!
I have been fortunate enough to have worked with and learned from some incredibly talented engineers, and I truly believe that incorporating these three tips into your team's workflow will have a profound effect on the team's efficiency and the overall quality of the code.
If your team is struggling to adopt these practices, we can help! At Evaluates2 we provide group workshops, full-time on-site consultants, and impartial expert opinions to help you and your team(s) build better software, faster. Don't hesitate to contact us today!
RSS Feed