“Working software” – How is it made?
Here’s the secret sauce – Working software is really about the people who build it. Working software is built by professionals. And professionals are not just tech wizards. They write software in specific effective ways.
What practices do we have in our disposal, that make us professional?
Think about it: As developers, our goal is not to push more code out the door. It is not to use the newest, shiniest framework. We have two goals: Produce code that solves the customer problems, and maintain that code at the lowest cost possible. As professionals, we do what we can to achieve these goals.
What kind of tools do we have in our bag that can help us? You’ll recognize the practices right away.
Let’s split those into groups. according to the two goals:
Building the right thing
- Requirement reviews
In scrum we call these “grooming” or “pre-planning” and “planning”, but these are not exactly the words to describe the developers understanding what needs to be done. A “review” can have different methods, from the product person describing the problem and the team comes up with options, to the product laying the entire plan he thought of before and the team needs to do their bidding. Regardless, this stage is essential to lower the risk of building the wrong thing. It is the first feedback provider on our way forward. - Whole team collaboration with the business/devops/test
All agile methodologies focus on continuous whole-team collaboration. Anyone who is needed to answer questions or discuss alternatives, explain more or offer more insight is available. The continuous flow of information and feedback into the production area reduces risk of building the wrong thing. - Monitoring live software
I’ve put that into a special bracket, because today collaboration between operations, business, development and testing goes beyond the inner sanctum of product development. Feedback of usage, behaviors and diagnostics go directly into the whole team for analysis and response. This is the actual feedback team is looking for, again, directing information on what is needed to build.
There’s a lot of product management involved in making the requirements into something buildable, that comes both before, during and after the team gets the information. We’ll focus more on the interaction, rather than product management activities.
Building the thing right
Since we want to build software that both works, and is maintainable, we have a lot going for us, once we have enough information. I’m going to split those into categories that may seem sequential, but in reality all are usually done continuously.
- Research and POCs – Trying out different solutions, checking out the technology and exposing risks early. Another built-in feedback cycle.
- Design review – Before we head on to the keyboard, review the proposed design (I’m using the word “design” here as a “solution to the problem”), discuss alternatives and agree on a starting point. It is a good place to mention XP’s value of “simple design”, since the design review is where we can also discuss the simplicity of the proposed solutions. In everything agile, “inspect and adapt” is the main motto. Nothing says more so than a design review.
- Pair/Mob programming – Building by yourself may be the “efficient” way to go, but doing it together with other pairs of eyes, not only is more effective on so many levels, it’s even more productive. It gets the work done, with agreement from others, getting feedback on the spot and responding to it, all in a more focused (sometimes exhaustive) way to get the job done. And you get all the benefits of code reviews.
- Code review – “Inspect and adapt” leads us here as well, to modify what we’ve just produced. It’s where we get feedback on how we built the product, and inspect the result, and then decide what to do next.
- Refactoring – It’s just part of the job, right? Well, so is everything else. Refactoring means going back into the code that “worked” in the first place. Refactoring makes the code not only functional, but also maintainable.
- Automated unit/integration/system/end-to-end tests and TDD – Automated tests give us feedback. Like the different reviews, once the safeguards are there, we can do something about it. The automation helps get the feedback early, rather than too late. TDD is where we get even earlier feedback before we’ve written the code. It’s like magic!
- Continuous Integration – All the automation is nice when it’s running “on my computer”, but CI enables feedback at the team level, as in “you’ve ruined it for everybody”. However, is still better than finding about integration issues in production.
- Shared code – maintainable code is only as good as its authors. If no one can go in but you, the dependency hampers the team’s productivity, and therefore the fact that everyone can and should go into “the” code is essential to having maintainable code.
- Testing – The classic product feedback generator. Whether it’s through automated tests, or exploratory, it’s the final “inspect” part before we deploy, and therefore the most important in terms of functionality.
But it doesn’t have to be just about that, because testability is an input into the software design. The “adapt” part here is not just fixing bugs.
You didn’t think you had so many tools at your disposal, did you? As you can see, the cycles of feedback are already built into these activities, because in essence, we need to prove what we built stands against all kinds of inspection.
If you’re missing one of those, you can adapt (see what I did there?) and increase your productivity by adding incorporating those practices into your development process.
There’s a lot to process here, but we’ll start the series with code reviews, my first pick for the most important thing you can start doing tomorrow.
| Published on Java Code Geeks with permission by Gil Zilberfeld, partner at our JCG program. See the original article here: Getting to Working Software – Introduction Opinions expressed by Java Code Geeks contributors are their own. |
