In the debate between developers and their employers, fixing technical debt is often seen as a cost center, a time suck that takes away from feature work. After all, when there are features to ship and clients to satisfy, taking the team off such projects so that they can rewrite what already works is seen as silly, costly or foolish.
But smart employers recognize that technical debt is more than an annoyance or a cost center. They recognize that technical debt has a chance of costing them good developers.
Dealing with errors is one of the most frustrating and challenging parts of developing an application. Nobody likes to think about their application in a failure state, and there’s nothing more deflating than writing a bunch of great code, and getting a message that you forgot a semicolon on line 4.
After trying a few packages and becoming frustrated with the nature of the available packages, I decided to write one. I called it BooBoo, because everyone makes mistakes. BooBoo is a package for error handling in PHP.
There’s been a lot made in the last 24 hours about the process of submitting and accepting conference talks, including whether or not such talks should be written beforehand. There are many valid points of view on the issue, and here are a few of my thoughts.
When it comes to creating conference talks, I typically start around November and come up with a few new abstracts focusing on topics I think or know are important in the PHP community. My general wheelhouse is focused mainly on the beginner to intermediate-level developer; rarely do I offer an advanced talk, mostly because I believe that conferences are best suited to the beginner and intermediate level developer.
Green field projects are certainly rare, but they hold a certain appeal over developers. The ability to ignore all the mistakes of the past, and instead focus on new architecture, new ideas and new methodologies is enticing. And yet, every pile of legacy code spaghetti out there was once a green field project, filled with the majestic hopes and dreams of the engineers who worked on it. What happens?
I know many developers who believe that code simply gets worse over time, that technical debt accumulations are inevitable and that bad decisions haunt us forever. But the truth is that code doesn’t rust. And that means that our ability to make changes is directly related to how well we create the code in the first place.
Good parents teach their children from a young age not to talk to complete strangers, and to tell mom and dad if anyone approaches or tries to talk to them. It makes good sense; children are innocent and will generally believe anything an adult tells them. We do this to protect them.
In object-oriented programming, we have a similar principle for objects. We want to teach our objects not to “talk to strangers”, too. What is talking to strangers for objects? Talking to strangers is relying on objects that we weren’t given, or APIs we haven’t been taught. For example:
It’s a well-accepted concept that code review improves the quality of the code produced by your team. Many teams use code reviews, most famously at Mozilla, where every change bigger than a grammatical typo is reviewed by a peer.
Code reviews are effective because they put a second set of eyes on a particular bit of code, and force one developer to explain to another in clear language what that code does. It’s difficult to get an overly-complicated bit of code reviewed, simply because the reviewer may not be able to understand it, and the chances of getting bad code into the system are greatly reduced by using the code review system.