Understanding Software Engineering with Graphs

Revision 4
© 2016-2018 by Zack Smith. All rights reserved.

All too frequently management gurus will make declarations such as practice X is good for your business when in reality it is rarely the case that any amount of X is a good idea-- there is an ideal amount that may be greater than zero, and perhaps too little can be harmful, and too much can ruin a business. Management gurus are like a bad rash; they aren't a solution to a problem, they're a symptom of a problem.

So herein I offer my graphs that propose the ideal mounts for some practices in different aspects of software engineering.

The efficiency cliffs

efficiency cliffs

What can we learn from this graph?

  1. Project project management software should not be onerous. It should be easy to use and a light burden.
  2. The project manager who requires use of the software should never seek to become the focus of attention.
  3. The project manager should act like a prince who is the focus.
  4. The project manager should not become a dictator (micromanager).

Each successive breakdown reduces programmer efficiency and brings a company closer to looking like a failed state.

The code resilience problem

code resilience

What can we learn from this graph? In different environments, standards are different. Please don't add comments to your code is what one start-up CEO was overheard saying. Many a CEO has no idea how to do proper engineering.

  • When standards are low, code is less resilient.
  • When code is less resilient, changes to it are less predictable.
  • When expertise is ignored, expect disaster.
  • When evangelical thinking takes hold, it's time to board the lifeboats.

The hasty debugging trap

debugging trap

Whether debugging goes well often depends on how the organization responds to crisis. If everyone panics at the smallest problem, debugging will be rushed, and bugs will beget bugs. If bug reports are unclear and the bug reporter refuses to clarify, bugs might not be fixed properly. And so on.

The distractions conundrum

distractions conundrum

People, typically HR people and managers, often suggest it's great to work in an open environment. This is a proven falsehood. In many ways, office noise is the new second-hand smoke. Can you really get into the zone when the marketing people are babbling about the Kardashians? No, of course not. And yet for some, no noise is not a good thing either. One size does not fit all. If people are working shoulder to shoulder, even typing noise can be a distraction (especially if the keyboard is any good).

Jason Fried TED talk

The management zone

management zone

Good management skills take years to acquire, and half of the learning is about one's own self. Management is not a higher caste, nor a higher class, nor a privilege. In fact, done right it's merely a service job. It's about stepping out of the way and helping the workers do their best work.

  • Good managers debate, they don't decree.
  • Good managers are humble, not braggards nor bullies nor burdened by egotism.
  • Good managers encourage exploration, not copying.
  • Good managers enjoy losing arguments when they are wrong.

The programming zone

programming zone

It happens.