the benefit of sneezing code into an editor vs clean code

The Benefit of Sneezing Code Into an Editor vs Clean Code

#sneezingcodejoind.in/11457

@dave1010Dave Hulbert

@dave1010Dave Hulbert

The Benefit of Sneezing Code Into an Editor vs Clean Code

Balance

Delivering fast is good

Good code is good

Analogy

Aims

● How to run fast (in general)● How to sprint (sneeze)● How to run a marathon (clean code)● Why you should sprint● Why you should run a marathon

How to run fast (in general)

● Developers– Skilled, Passionate, Healthy, Focused, Disciplined– (Relevant) conferences, user groups (hello)– Read books, blogs, code– Write code, Open Source contributions

How to run fast (in general)

● Projects– Good communication– Good specifications / requirements– Fast feedback– Good clients

How to run slow (in general)

● Complexity– Code / System

● Bad / slow / no tests● Bugs● Lack of investment

– Servers / Workstations / Software

How to run slow (in general)

● Interruptions● Being blocked / waiting● Internal processes● Too many meetings

Aims


How to sprint (sneeze)

● What is sprinting?

How to sprint (sneeze)

● Overtime● Ignore everything else● Reduce tests / testing● Reduce planning● Reduce communication● Outsource● Cut corners● Focus; don't improve tools / processes● Outsource

Technical Debt

● What is technical debt?

Causes of technical debt

● Deciding to release before it's ready● Deciding to use a RAD framework● Deciding to skip tests & documentation● Lack of understanding (requirements, code)● Premature optimisation● Software entropy

Consequences of technical debt

● Interest; interest on interest● More time on maintenance● Less time on new features● Harder to estimate new features● Miss deadlines

Aims


How to run a marathon(clean code)

● Non-code speed-ups: time & money investment– Staff training– Tools and processes– Planning / requirements

How to run a marathon(clean code)

● Clean Code (Uncle Bob)– SOLID

● TDD– Run every bit of code that you write, ASAP

● DDD– Model the domain completely in PHP classes that

don't touch the UI, database or framework

Refactoring

Refactoring

● Key to keeping up speed in big projects● Restructuring without changing behaviour● No direct measurable user benefit (not a user

story)● Makes it easier to read, understand, test,

change, add new features to● IDE makes refactoring easier

Refactoring

● Inject dependencies● Decouple (fewer “use” statements)● Create interfaces to type hint to● Extract functions● Rename● Reduce cyclomatic complexity (number of

if/else/for/foreach/while/switch in a method)● Change depth of inheritance

Examples

● Journey Planner● User API

Aims


Why you should sprint

● Help you deliver faster in the short term● Long term strategy● MVP (prove a theory)● Disposable prototype

Why you should sprint

● Treat your servers like cattle, not pets● Sometimes code is similar

Examples

● Laravel– RAD framework– Sacrifices SOLID code (a bit) for ease of use– Static “facades” (instead of using injected

dependencies)– $user->save() (instead of $userRepository-

>persist($user) )

Examples

● WordPress– “5 minute install”– Low barrier to entry– Lots of themes and plugins

Aims


Why you should run a marathon

● Technical debt is a risk– Especially with big projects

● Quality is valuable● Deliver faster in the long term

Aims


Sprint vs Marathon

Sprint (example) Marathon (example)

Peripheral component (logs) Central component (DB)

Trivial (make a CSV) Complex (search algorithm)

Few consequences of bugs (game) Important (nuclear reactor)

Isolated (contact form) Reused (authentication)

Abandonable (migration script) Continued updates

One developer Big team

Time & money to pay technical debt later

Long term delivery

Bonus: estimating

● Estimates for new features need to include refactoring– (if you don't want to increase technical debt)– Refactoring doesn't add perceived value so it's

hard to sell● Technical debt is expensive

– Sprint + paying technical debt interest costs more than running a marathon + continual refactoring

Bonus: Testing

● TDD is about running your code ASAP● Write a test when you fix a bug● Fix bugs before writing new code (The Joel

Test)

Wish list

● A script to track TODOs over time (Jenkins?)● A tool that helps you decide whether to

sprint or run a marathon

Resources

● Books that I've read at least a few chapters of– Mythical Man-Month: Essays on Software Engineering,

Frederick Brooks– Clean Code: A Handbook of Agile Software

Craftsmanship, Robert C Martin– Implementing Domain-Driven Design, Vaughn Vernon– Modernizing Legacy Applications In PHP, Paul M.

Jones– More: http://amzn.to/Y29TAK

http://amzn.to/Y29TAK

Resources

● Refactoring http://refactoring.com/catalog/● Speed in Software Development

http://www.targetprocess.com/articles/speed-in-software-development.html

● Technical debt http://www.construx.com/10x_Software_Development/Technical_Debt/

● Images: HBO, Reddit, XKCD, the Internet

http://refactoring.com/catalog/



http://www.construx.com/10x_Software_Development/Technical_Debt/

http://www.construx.com/10x_Software_Development/Technical_Debt/

Thanks!

#sneezingcode

joind.in/11457

@dave1010

Dave Hulbert