As mayor of New York City in the mid to late 1990s, Rudy Giuliani was largely credited with a significant drop in crime rates during his tenure. His success was attributed to his adoption of the broken windows theory of policing, which broadly goes along the lines that a zero tolerance policy toward petty crimes such as graffiti, turnstile jumping or begging in the streets pays dividends in terms of reducing more serious crime.
Although the broken windows theory has been questioned more recently as it applies to policing, nonetheless Giuliani (who by the way was a Lotusphere keynote speaker in 2003) was lauded at the time for his adoption of the policy and the resulting drop in crime rates in the following years.
Speaking of Lotusphere, if you've ever visited a Disney theme park, you'll have noticed how uncannily clean and tidy the streets are. You'll be hard pressed to find a piece of trash or a cigarette butt anywhere. Reportedly Walt Disney maintained that, by making it part of every employee's job description to pick up any trash they saw, he would make the streets of the Disney parks so clean that people would be embarrassed to throw anything on the ground. Whether it's true or not, it's a nice story, and entirely believable, in my opinion.
By the way, a compelling need to keep your surroundings neat and tidy doesn't only apply to Disney property. At the recent World Cup tournament in Russia (that's soccer, to our American contingent), the Japanese fans and players gained a reputation for staying behind after the match to clean up the stadium.
Whatever the application, the theory is the same. If you keep your environment spick and span, it will encourage others to do the same. If you let things go a little, everyone will follow suit and you'll quickly end up with a mess.
The concept of broken windows was adopted by the software development community many years ago. The theory, which I personally think has a lot of merit, is that broken windows, which in this case refers to bad coding decisions, things that the developer didn't have time (or couldn't be bothered) to fix, lead to a general sense in the team that the code is in a state of disrepair, which makes it less likely that others will take the required amount of care in their coding. To quote from the Pragmatic Programmers' article:
As soon as something is broken—whether it is a bug in the code, a problem with your process, a bad requirement, bad documentation—something you know is just wrong, you really have to stop and address it right then and there. Just fix it. And if you just can't fix it, put up police tape around it. Nail plywood over it. Make sure everybody knows it is broken, that they shouldn't trust it, shouldn't go near it. It is as important to show you are on top of the situation as it is to actually fix the problem. As soon as something is broken and not fixed, it starts spreading a malaise across the team. "Well, that's broken. Oh I just broke that. Oh well."
Here at Teamstudio, we live by this stuff. It may surprise you to learn that there is still some code in our software products that was written more than 20 years ago. And although we don't encounter much staff turnover in our development team, there have been a number of different people who've had their hands on the code over the years. It's actually in remarkably good shape considering its age, and that's largely because we are careful to keep things clean as we go along. Also, each new release (we're working on E33 now) includes a good amount of cleanup activity.
The older the code base, and the more people who've worked on it, the more time you have to spend on cleaning - picking up on things that are not quite as they should be and fixing them - which doesn't add any new features at all. But if left unchecked, these things actually prevent you from being able to add features because you run the risk of unwittingly breaking things elsewhere in the application. So it's well worth the time investment.
The same principle applies to the Lotus Notes applications that our customers continue to maintain. Many of those applications have been around for a long time, and many of them have been worked on by a number of different people over the years. In some cases, the Notes development teams have been downsized or even completely let go, leaving contractors or staff with very little experience of Notes development to maintain the apps. In these situations, it's even more important to invest time into clean up efforts to ensure that the applications will be maintainable for years to come. Unless of course the plan is to migrate these applications to some other platform, in which case the best approach is undoubtedly to rewrite the whole thing from scratch.
Tooling can help with the clean up effort. Teamstudio Analyzer is a great place to start if you have an application that's been around for a long time and has been built and maintained by a cast of thousands. We've written before about how Analyzer can help you find your way around someone else's code, and it can also help find inheritance and dependancies - in other words it can answer the question "if I change this, what else will be impacted?"
For a more general application health check, take a look at Teamstudio Validator. Validator will find inconsistencies between data and application design, for example spotting field data that will never be surfaced on a form, keywords in data that are not in the corresponding field definition, or missing dependancies. It can also identify broken links, orphaned documents and many other issues.
If you're maintaining applications that people are actually using, I would encourage you to put some thought into this issue. For many older applications, it may be too late to adopt the Disney approach of keeping your code so clean that anyone would be embarrassed to mess it up. But that doesn't mean you can't make a start on devoting some time and attention to clean up. Many of these applications have been around for a long time, and with Notes/Domino 10 and beyond on the horizon, many of them will be around for a long time to come.
If you're grappling with issues around maintaining older Notes/Domino applications, click below to start a conversation. We're always happy to chat!