It’s becoming more and more difficult to identify areas of life that don’t depend on software. Yet it may surprise you that much of the software we use every day is poorly written and designed, has little code coverage, and has created in users such low expectations that people – despite much bellyaching – simply put up with.
Agile software developers are among a small group of people who care about code quality and treat it like an art. SolutionsIQ’s Dave Wylie has a passion for excellence in software engineering. In a recent Agile Amped podcast, he shared seven drivers for why businesses need to pay attention to the quality of their code and invest in their development organization.
1. Science and data support it. We still aren’t putting into practice good science that we’ve known about for more than three decades.
We’ve known for a long time, before Agile was even named, that there are good practices the development team should do. They should test their code, they should review their code, they should integrate with other teams building programs, they should work with the business and make sure that we’re building the right thing. It’s our responsibility, as developers, to build the thing right, but we need to work with people to help us get feedback. We have to become stewards of this asset, this codebase… Kent Beck was starting to do this literally 22 years ago. We’ve known these practices. Steve McConnell published “The Low Hanging Fruit” 30 years ago about these practices.
2. “Every company is a software company,” so support those who physically create the software.
Those foundational practices – writing tests, reviewing code, integrating the code, making the code better – are important for everybody. One of my colleagues says, “Who’s responsible for maintaining and not degrading this corporate asset that we’re creating?” We’re spending such a huge percentage of corporate budgets on the software. The quality of that asset, the ability of that asset to meet current needs and be ready for future needs – that’s in the hands of these delivery teams. We need to make sure that we’re giving the delivery team direction and guidance and training and support to make sure that this asset is both enhanced and extended and not degraded and eroded.
3. While possible and even expected, good development practices aren’t the norm. This is a huge business opportunity waiting to be addressed.
The VersionOne survey that they do every year on Agile practices shows us pretty consistently that about 30% of the people are doing test-driven development, about 30% of people are doing pairing, less are doing more advanced practices like behavior-driven design, or things like that. We’ve improved on some things like unit testing, but doing them all the time? That is still fairly unusual, that’s what the data is telling us…
One reason is that good software developers are often promoted out of development, while replacements often don’t know good practices.
The reality is, many people in development don’t know these good practices, the development and QA and tech writing and operations tend to be entry-level positions. In certain cultures, the people that have done this for three to five years, they get promoted to management… It’s relatively unusual across the world to have developers with 20 years’ experience. Most developers have three years’ experience.
We need to value the “hands on keyboard” people, “hands dirty” people, we need to value them and pay them and give them career paths that allows them to keep their hands on the keyboard. Again, it’s a real disservice to say, “You’ve hit five or eight years so you now become a manager and you don’t get to code anymore.” Well, that’s a bummer. We just took some of our best, most passionate people and took them away from the ability to help create these corporate assets.
Another reason is that few developers have formal training and mentoring in high-quality software engineering.
Unfortunately, so many of the developers that are in our ecosystems now haven’t had a good mentor and have not had formal training. The beauty of the Internet is it has democratized development. There’s lots and lots of people in the software development world that have had zero formal or informal training or mentorship on these practices… Yet there’s little time or money for you to go sharpen your saw, to go get better, to learn, to go to the conferences and be better and do these practices, whether it’s on a week a year or an afternoon a month on how do you get better.
4. The difference between high-performing teams and average teams makes it well worth the business investment.
If you just look in the marketplace and see some of these innovations, they’re coming from these excellent teams that are doing these excellent practices. Some of the big dot.com companies, the web companies, they’re implementing thousands of times a day. If you’re in corporate America, if you’re an insurance company or bank saying something like, “Yeah, we go live once a quarter or something like that, that’s our release plan.” [Releasing so infrequently] is inconceivable. You’re speaking Martian. The federal government has people [releasing value rapidly]. The military has people figuring out how we can implement on a regular cadence and foundational to that are these software development practices.
5. By getting involved, the business gets more transparency into quality, velocity and expectations.
Step one is go talk to your teams. The Japanese call that Gemba, go to where the work is being done. Go work with your teams. If your teams are remote, get on an airplane and go see them and see how they’re working, see – are they working together or they work in individual cubes or separate floors? I see these horrible instances where QA’s on one floor and Dev’s on another and OPS is in a different building and the product people are in another city. Guess what? That’s not going to be as effective as it could be. So, go see, number one. Oh, by the way, this is going to require some change and effort on management’s part.
It means every day you should be working with those developers and ask them, “Can I see the working code? Show me what you did yesterday. Can I see this? Can I see either the status of the build or can I see a component, a story? When a story is done, show it to me. I want to see working software.”
6. Iron-Triangle contracts – fixed scope, fixed date, fixed budget – lead to bad quality products. Focus on working products.
If you’re working for an outsourced person they’re focused on a tough date and a lot of scope – fixed scope, fixed date, “Iron Triangle” kind of problems. Jerry Weinberg said years ago, “As long as the software doesn’t have to work, I can meet any constraints.” That’s the Zeroth Law of software. I’ve seen places where “the software doesn’t compile, but we’ll meet the date to go into QA for you. We’ll trust QA to find all our problems…” It’s crazy how many times people try to weasel out of showing you working software.
7. Better software is more secure.
I saw an example from Department of Homeland Security. They said [to their vendors], “If you’re going to be a vendor for us, here’s what we’re going to expect from you.” That’s publicly accessible documents that people should look at from a procurement perspective that say, “I expect you not only to deliver code to me. I want to see that you’ve got good test coverage. I want to see that you’ve integrated and that you don’t have lots and lots of branches in things and I want to see this on, not every month or every three months, I want to see it on a daily basis.”
If you build this safety net of tests and Continuous Integration and pairing review – because you’re spending less time in your mistakes, you’re actually spending more time delivering features. This is where we start to get to that 2X, 3X, 10X functional delivery of people. If you have a team that’s having to struggle delivering, they’re probably not doing these practices. If you’ve got a team that is delivering and making Product Owners or is happy there’s a good chance, they’re doing some, if not all, these practices.