#begin
The next chapter dives a bit deeper into these fundamental principles of engineering. The fun fact is that for each type of engineering these fundamentals might be a bit different. So what might they be for SE?
Well first of all; Technology and Software is an industry of change. No questions there. Software is ever evolving to keep up with technology changes and vice versa. In the past the hardware was evolving so quickly that software just didn’t need to evolve as fast. I don’t know how many times I’ve heard these old software guru’s say things like: “In the old days, in order to make your software run faster was to wait for 18 months.” This had to do with Moore’s law (RIP, he passed away March 24th 2023).
So back in the day when they were doing waterfall processes and the software wasn’t fast enough they could simply stretch the process and make it faster by merely waiting. That’s a bit over exaggerated I suppose but there is some truth in there. I wonder if this actually happened.
Probably…
Software however has not evolved as fast as hardware. We are constantly reiterating on old idea’s. It might seem new but it’s just rehashes of old stuff. Uncle Bob talks about this a lot as well. Micro services for example is just SOA. “New” programming languages aren’t presenting new ideas. They just combine old ideas in different interesting ways. Maybe the borrowing mechanism in RUST is new but it’s still a lot like C++. So discarding old ideas seems to be pretty difficult while inviting new ones is too.
David says that we find it difficult to discard old ideas because we don’t really measure our performance in software development very effectively. We measure things like velocity of maybe even lines of code written. Which is stupid in my opinion. Or maybe test coverage, which doesn’t make much sense either. David refers to the DevOps reports and the Accelerate book for interesting measurements. I think we have all heard about these two before. If you have been listening to popular podcasts of conference talks these must be known to you.
If not, go check them out they are really interesting.
The moral of the story from is that teams with high stability and throughput are classified as high performers, while teams that score low on stability and throughput are low performers. David mentions Continuous Delivery to be at the core of high performance teams. He wrote a book called Continuous Delivery, also a very good read, so I’m pretty sure he knows what he’s talking about. Continuous Delivery practices really pin down on the values of DevOps.
I think that DevOps and Continuous Delivery are often used interchangeably but that don’t mean the same thing. DevOps is more than just CD, it’s also CI, security, testing, and probably more. All of this is implied by CD but they shouldn’t be confused I think.
But stability and throughput provide you with some model on how to predict team outcomes. Both of them are tracked by two measures.
Stability is tracked by:
Change Failure Rate: The rate at which change introduces a defect at a particular point in the process.
Recovery Failure Time: How long to recover from a failure at a particular point in the process.
Throughput is measured by:
Lead Time: A measure of the efficiency of the development process. How long for a single-line change to go from idea to working software.
Frequency: A measure of speed. How often are changed deployed into production.
So stability is a measure of quality and throughput is a measure for a team’s efficiency at delivering ideas. David then mentions that the Accelerate book tries to dispel the belief that “You can have either speed or quality but not both.” With these two measures you can get speed and quality!
He says: “The route to speed is high-quality software, the route to high-quality software is speed of feedback and the route to both is great engineering”.
Now that’s a great quote isn’t it. It seems so easy, but it’s not simple.
But when we apply stability and throughput, we need to make it measurable. David talks about how change approval boards are a bad way of trying to achieve this. Mostly because we don’t measure things properly.
According to David we need to apply a more evidence-based, scientifically rational approach to decision making. We need to measure the stability and throughput of wat we are doing right now, make a change, and measure again. It’s that simple really.
The accelerate book describes an approach to measurement and this model is being researched and is still evolving. So you can use the model from the book to get started with a proven approach. So, we finally have a useful measuring stick!
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments