Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Project clarity - random rant from an old engineer

Project clarity - random rant from an old engineer

Nikita Salnikov-Tarnovski

February 21, 2019
Tweet

More Decks by Nikita Salnikov-Tarnovski

Other Decks in Programming

Transcript

  1. Disclaimer • This is a rant born by 20y in

    industry • I speak opinions, not truths
  2. Who am I • 25 years of programming • 20

    years of programming for money • 18 years of team work on big-ish projects • Projects I was in: old, new, optimistic, doomed, impossible-but-fun, government, startups
  3. Green-field project • Everybody loves new projects • It’s like

    all-inclusive with full bar and a chocolate shop for kids • And very high hopes for “we will do better this time!”
  4. Legacy projects • Nobody loves them • It is almost

    a swearing word, “legacy” • Fragile tests, old technologies, sky-rocketing WTF/line metric
  5. “Programs must be written for people to read, and only

    incidentally for machines to execute” (c) SICP
  6. Paying your debt • “After this release we have to

    spend 2 weeks tying loose ends and fixing short-cuts!” • “We need 10% of the time for handling technical debt!”
  7. What it really means I was doing crappy job. Now

    give me extra time to do a good job.
  8. Cut the crap • If you do your job badly,

    then ask for more time to fix it •It is your fault •You damage the project AND your reputation
  9. Constant improvement • You have to strive for the best

    possible quality given all the constraints • 90%* of all improvements can be made by tiny steps during your day to day job *Extremely scientific measurement
  10. Bigger projects • Some problems cannot be fixed by tiny

    steps • They need focused effort and many person-weeks • But usually they are big enough for even the management to know about them
  11. Conventions • Agree on conventions and stick to them •Locations

    •Naming •Code formatting •Communication protocols
  12. Learning curve • We start simple, because we don’t know

    anything yet • We learn, we become smart and our toolbox grows • But this is not enough
  13. Simple is hard • Simple code for simple problem is

    easy • Complex code for complex problems is possible • Simple code for complex problems is hard • It requires aspiration and discipline
  14. Simplify everything Perfection is achieved not when there is nothing

    more to add, but when there is nothing left to take away
  15. Ubiquitous language • Developers and business must speak same language

    • Both meetings and codebase should use same words
  16. Constant effort • If you see discrepancy - fix it

    • Change your code to align with changed business
  17. Why documentation? • Not to explain what code does •It

    should be clear from names • Not to explain how code does it •Code itself explains it better, DRY • To explain WHY code does it
  18. Most precious knowledge • Why some decision was made •

    Why this solution was chosen •And what and why was not chosen
  19. The more the better • Comments • Commit messages •

    PR descriptions • README • Architectural decisions log/history
  20. Fitness functions • Description of some important aspect of your

    system • Both technical, functional and anything else
  21. Clarity as a Function • You can formalise clarity as

    a fitness function • And then monitor it
  22. Quality gates • But monitoring and reacting does not work

    • Prevent bad things from entering your code
  23. Quality gates • Every aspect that you care about can

    be (auto)checked • Your CI should always try to find an excuse for rejection
  24. You can check everything • Code complexity • Spelling •

    CVE • Unit-test performance • Code structure • Libraries licenses • Formating • Code smells • YAML syntax • lint • Number of FIXME • Dependencies versions • Documentation • Image resolutions • Swear words per class • Cross-compilation
  25. Baseline • There are tons of problems in any existing

    project • Reject changes if their number increases • Boy-scouts will take care of old ones
  26. Local run • Quality gates are useless, if only CI

    can run them • Every developer should be able to • With the same configuration as CI
  27. Code review • Ultimate litmus test: •Can another developer understand

    your code? • Opportunity to discuss simpler solution
  28. Solving performance problems is hard. We don’t think it needs

    to be. @JavaPlumbr/@iNikem http://plumbr.eu