Part 1 in a series.
Every discipline has best practices. These are the behaviors and skills that contribute the most to success. They aren’t objectives in themselves. You don’t “complete” a best practice and then you’re done. Best practices are perspectives and disciplines that you always apply almost every day to make you better at what you do.
To illustrate, I heard a story once about salespeople taking training classes at a conference. All the younger sales folks were going to the cool classes about new sales techniques, the latest psychology of sales, etc. But the more experienced salespeople were going to classes on how to negotiate better, how to close the sale, how to do a better job of networking, etc.
You might wonder why the more experienced people were going to those basic sales classes instead of classes about special circumstances or new trends in sales. The reason is because those basics – negotiating, advancing the sale to the next level, connecting with customers – are fundamental practices that contribute the most to being successful with sales. Negotiation and advancing the sale may be 50% or 80% of actually making a sale. Getting better in those areas, even if they’re areas you’re already good at, will give you more “bang for the buck” for your efforts.
Another example: When I was doing karate, the particular school I was in insisted that you memorize a bunch of tenants and purposes of that particular style. The very first one was “Practice basic techniques all the time”. And every class we did so.
Why practice the most basic blocks and kicks all the time after already practicing them for years? Because they focus on balance, on protecting your must vulnerable areas, on improving your core and speed. These are the things that not only give you the foundation to do dramatic (but not very effective) jump-spinning kicks. They also continue to make you better dealing with the kinds of attacks and defenses that you’re most likely to encounter. Block, block, kick, punch. Don’t worry about flying through the air, just avoid getting hit and disable your opponent. Or better yet, run away!
It’s the same for software development. There are fundamental practices that transcend technology and fads. If you get good at those areas you’ll significantly reduce your risk of failure, you’ll be much more likely to create a product that will solve someone’s problems, and you’ll create more robust and high-quality software. If you don’t focus on those best practices, you’re much more likely to fail to deliver a product on-time that solves someone’s problems.
I started to learn best practices by failing a lot. Like many people, I finally started to migrate to doing what seemed to work and avoiding what didn’t. In fact, after you work on some projects over the years, you can start to “smell failure”. That’s the visceral sense of dread you get when you see too many things happening that just aren’t right. When this happens, you’ve started to get a sense that best practices (even if dimly perceived) are not being performed. Run away!
Rational Software (later purchased by IBM) defined 6 specific best practices of software development and organized their products and solutions around them. That was GREAT! We could actually talk to customers about how to solve their problems and discuss where their shortcomings were. For almost 15 years I’ve used the thinking around those practices to help lots of people get better at delivering software.
These days, it feels to me like we have less understanding of what these best practices are in our industry. Teams do “agile” (whatever that means nowadays), or they repeat what their organization has done for many years, or they just make it up as they go along. While we’ve come a long way over the last 30 years, we’re still addressing the same kinds of problems. And we still need to address the same best practices to be successful.
One more thing about best practices in our industry: they give us a way to help measure the value we deliver. Measuring value can be hard. Is a programmer good because he writes three times as much code as someone else, or is the other person better because it’s hard to find bugs in her code? Is a tester good because she finds a lot of bugs, or is the other tester better because he identifies ways for developers to avoid writing bugs? Is an analyst good because he writes requirements that people can understand? Or is the other person better because she writes requirements that developers can design from?
The fact is, bad software can succeed with good marketing. Good software can fail in the marketplace even if the developers are delivering on their minimum SLOCs. Rewards and punishments for these kinds of results may have little to do with the skills of the practitioners and their contributions. It’s often hard to draw that line between what a practitioner does and the success of a specific product.
So instead of looking at how well a product does in the market as a way to reward practitioners, we want to encourage the behavior that’s most likely to make the product successful, and discourage behavior that won’t. If we identify best practices, we can focus on encouraging behavior that realizes those practices. It doesn’t guarantee success or assure failure will be avoided. But it does give use a way to perform that is more likely to make us successful. That’s what we should be measured by.
I thought I’d do a series of blogs on the best practices for software development as I see them. There aren’t very many practices, but they cover large areas. I would love to see the industry re-dedicate itself to best practices instead of embracing are dearly loved process philosophies. Software development processes should make us better at performing best practices, not be ends unto themselves.
Here are the best practices I’ll be covering in future posts. Stay tuned!
- Define the problem and a general solution. If you only do one thing right, do this.
- Manage requirements. At the least, manage the 20% of critical requirements.
- Test continuously. Like voting in Chicago, do it early and often.
- Deliver iteratively. Always get back to solid ground, aka stable software.
- Model the software. The people currently in the room with you are not the only people who need to understand what you’re doing.
- Define the architecture. No, really. Define the architecture!