Re-reading technical books always makes sense. Usually I don't remember anything I read on them once I finish, but while I'm reading I get all sorts of epiphanies, mostly related to the project I'm working on at that point in time. Basically, when you read a book, any book, you are a different person so you pay attention and make connections to different things.
I'm reading now
The Pragmatic Programmer, an all time classic for programmers. For starters, they seem to be the people who coined the term
DRY,
Don't Repeat Yourself. Might sound like a minor achievement, but being able to
create new words and terms that allow people to communicate faster and better is a big deal. See, now when you hear someone talking about making apps more "web 2.0" or "harness the power of social media" the bullshit alarm in your brain automatically goes off and you get a quick idea of who you are talking to. Very useful.
The building with the broken windowVery early on the book they talk about something that is very true both in programming and real life. Researchers found that in a building, once a window breaks and it's not fixed in a reasonable amount of time, the state of said building declines very, very fast. We see this all the time. Whenever something is clean, everyone follows and tries to keep it clean. But as soon as the garbage is left out for too long, people start letting themselves go. Very, very soon, the mindset goes from "wow, can't leave that rubbish there" to "fuck it, everything looks shit".
In software projects at the beginning everyone is happy and the rainbow is high up in the sky, but soon enough someone
breaks a window. It might be using a literal here cause you don't have time now to get hold of the config object or making a method public cause it simplifies so much getting the data out of the component, even if that breaks encapsulation.
How to tackle the problemFire the developer that breaks the window and doesn't fix it in time? Too harsh? Is breaking windows a necessary evil from time to time? It really isn't, but, for the sake of the pragmatic people (tight deadline, client wants this, today I was tired, etc), let's assume breaking windows in inevitable. I can live with that. But we shouldn't live with the broken window for too long or devs will start not caring very fast. What once was a nice and clean system can turn very quickly into a mess nobody wants to touch.
If threatening to fire developers might not go down well, what about threatening them with superstition?
Exodus 23:10And six years thou shalt sow thy land, and shalt gather in the fruits thereof: But the seventh year thou shalt let it rest and lie still
This I think I picked up from Chris Heilmann at
StackOverflow DevDays. They say it in the sense that every 7th iteration (whatever long that is in your project), stop coding and clean up. I like it cause I think it brings a good balance between fast coding (I can hack this little thing now, code cleaning comes in 2 iterations) and keeping quality reasonable high.
Also this goes by hand with the idea of the
technical debt:
Doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like the financial debt, the technical debt incurs interest payments, which come in the form of extra effort that we have to do in the future development because the quick and dirty design choice. We can choose to continue paying interest, or we can pay down the principal by refactoring into a better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
It's ok to incur in some "debt" when you kick off the project, same as businesses incur in some real debt when they start. But at some point devs need to start paying back some of that debt or the interest (time wasted dealing with crappy code) grows exponentially.
Bottom line: it's ok to break a window from time to time, but it's not ok letting it broken forever. It will haunt you down : )