We’ve all been impeded by bad code, so why do we write it?
- Deadlines
- Want to move on to another project
- Endless backlogs
- Being slowed down by someone elses code
- A single change breaks 2 or 3 other parts of the code
- Modifications require ‘understanding’ in order to add them
- Productivity drops toward zero -> more staff is added to increase productivity -> new staff doesn’t understand the system design and their help thwarts efforts compounding the mess.
- Management finally agrees to a redesign a tiger team is selected
- They race to complete the new system while other teams maintain the old system
- They have to create all the functionality of the old system plus keep up with new changes
- By the time it’s done the current team doesn’t want the new system cause it’s such a mess.
We complain about managers and requirements but it’s us. It’s our responsibility to push back and tell managers it’s going to take more time to write our code.
- Elegant and efficient (it’s easy to write more bad code when the code is already bad because it looks like nobody cared in the first place)
- Does one thing well, is focused, single purpose
- Readable, literate, expressive, unsurprising, minimal
- Is easier for others to enhance
- Testable
- No duplication
- Most of the time when we're 'writing' code we're actually reading it. Our ratio of reading to writing code is 10:1. Therefore making it easier to read makes it easier to write.
- We can’t just write clean code, we have to keep it clean. Boy Scout Rule – leave the code cleaner than when you found it. Cleanup doesn’t have to be something big, improve a variable name or break up a function.