Mobile
My iOS apps
Other apps
Open source
  • Bandwidth benchmark
  • RAVM virtual machine
  • Big integer division
  • Prime numbers
  • AntiJOP sanitizer
  • TouchWidgets UI lib
  • Networking utils
  • Documentation
  • x86 instructions ref
  • GIT quick ref
  • GPG quick ref
  • Avoid Ubuntu
  • Android malware risks
  • iOS malware risks
  • OS/X security tips
  • Who blocks Tor
  • Software engineering
  • BASH aliases
  • I.B. pro/con
  • Vocal programming
  • Nutrition
  • Blog
  • Contact
    1 at zsmith dot co

    Understanding Software Engineering with Graphs

    Revision 4
    © by
    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

    Click to enlarge

    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

    Click to enlarge

    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

    Click to enlarge

    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

    Click to enlarge

    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

    Click to enlarge

    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 hubris.
    • Good managers encourage exploration, not copying.
    • Good managers enjoy losing arguments.

    The programming zone

    Click to enlarge

    It happens.




    © Zack Smith