
Written in a remarkably clear style, Creating a Software Engineering Culture presents a comprehensive approach to improving the quality and effectiveness of the software development process. In twenty chapters spread over six parts, Wiegers promotes the tactical changes required to support process improvement and high-quality software development. Throughout the text, Wiegers identifies scores of culture builders and culture killers, and he offers a wealth of references to resources for the software engineer, including seminars, conferences, publications, videos, and on-line information. With case studies on process improvement and software metrics programs and an entire Part on action planning (called "What to Do on Monday"), this practical book guides the reader in applying the concepts to real life. Topics include software culture concepts, team behaviors, the five dimensions of a software project, recognizing achievements, optimizing customer involvement, the project champion model, tools for sharing the vision, requirements traceability matrices, the capability maturity model, action planning, testing, inspections, metrics-based project estimation, the cost of quality, and much more! Principles from Part 1 * Never let your boss or your customer talk you into doing a bad job. * People need to feel the work they do is appreciated. * Ongoing education is every team member's responsibility. * Customer involvement is the most critical factor in software quality.
Too many companies focus on productivity and throughput instead of impact (of their features). So they produce bad features faster and faster.
One key difference is between informational metrics (e.g. using a scale to guide your own planning about diet and exercise) and motivational metrics (e.g. reporting your weight and being subject to weight loss targets associated with carrots and sticks.) Very different dynamics, most of which are harmful.
Don't let the underwhelming title fool you: it's largely a book on why it can't be done. Austin takes classical principal-agent models and extends it to add a third participant: the client. He then shows that difficult-to-observe work at first improves and then worsens under any metrics regime.
No single metric can be found that will give the desired performance. The basket of metrics that can successfully create the desired outcome is one where the principal has total visibility into the agent's work -- which contradicts the original problem of difficult-to-observe work (ie, anything requiring skill).
"Measuring and Managing Performance in Organizations"
Has a lot of information about how people react and adapt to setting KPIs, aka "gaming the system".
> I find pretty big differences in code that's written to meet the lowest bar of "just pass the tests" vs code that's written with the intent of keeping its state space small, methods tidy, and overall complexity limited.
I think maybe this is where the misunderstanding arises. I'm used to TDD which amongst other things places pressure on the codebase to remain testable. The things that make code testable also, roughly speaking, make it reusable as well (test code is just code, after all). But more important than any one practice or tool is people just giving a damn about doing the work well.
This might be an example of Goodhart's Law: if someone throws a test suite over a wall[^] and says "here, make these pass or you're outta here", then the motivation to cut corners is going to be intense. Attempts to create control loops over humans that rely on mechanical behaviour by humans tend to fail. Steering wheels don't have families and mortgages, wing flaps aren't thinking about their next promotion.
The best discussion I've read about the problems of using measurements and targets to control (in the engineering sense) skilled workers is Measuring and Managing Performance in Organizations by Robert D. Austin. He elegantly demonstrates that the less directly-observable the work, the more destructive attempts to externally control it are. Which fits with my updated understanding of what you intended to say.
[^] this doesn't have to be a current wall, either. It can be the wall of elapsed time: the flaky tests of yesteryear can be a very particular kind of curse.