Mending Broken Windows

Broken Windows

broken windows

As a test manager I have observed the principles of Broken windows theory in software, and struggle each day against it. The basic principle is that a window left broken in an old building soon results in more broken windows. It spreads to other buildings. Soon a whole estate is degrading, it’s not just broken windows and graffiti, but robberies and worse.

A couple of years ago I’d say our software was in the situation where nearly all the windows were broken, bugs were so easy to find. As time progressed the bugs got worse, session crashes, performance issues.

Our company had focused on rapid content build, making a solution that was easier to sell. It was the correct move at the time, it brought in sales!

After a while we noticed the hidden costs, content wasn’t used because it wasn’t of great quality, looked poor, was constantly suffering issues. Our culture had changed. Where there was once one broken window, soon there were many. Where once a single screen didn’t have a great layout, soon many had poor layout, soon there were many bugs, session crashes and performance issues. With many broken windows, people didn’t think it mattered any more, what’s one more broken window amongst a building of them.

Today it’s a different story for our product. Achieved through a lot of hard work, a change in expectations, not accepting less.

Change

In New York 15 years ago serious crime was a major problem. Today serious crime in New York is low. This wasn’t achieved overnight, a lot of work went into making it happen. Firstly came a change in attitude, police no longer tolerated petty crimes. A zero tolerance policy. The idea being that people changed their views of what was acceptable. This was accompanied by a large rise in police officers on the beat, which required the hiring of many new policemen, a serious investment in solving the problem. The officers weren’t just there to clamp down on the petty crimes. They got to know the people, build relationships, change attitudes. Stop catching and start preventing.

To change our software we had to change expectations, and we had to invest in that change.

Expectations

We worked on setting the expectations clearly. The product must work on specific resolutions on specific browsers. It must look good and adhere to design guidelines. Constant communication helped reinforce the expectations.

Acceptance

We also changed what we accepted, there was no excuse for it not working at the specified resolution on the specified browser, we had clearly set the expectation. Zero Tolerance.

“if you don’t have IE6, get access to IE6!”

Investment

It took a release cycle of re-working a large amount of code, the business agreed to that investment, and the results of our efforts are astounding. It amazes me each day the higher standard that our developers produce. It looks great and it works. Testers encounter far fewer defects when they first see the software, developers have already done their due diligence and often raise issues before we can. It was a fine line between being the enforcers and being members of the team trying to make a better product, changing attitudes. These days the tester isn’t seen negatively for raising issues, but their opinion is valued on making the best product.

Preventing future broken windows.

Testers have more time to look further afield now, raise expectations in other areas, make the software more usable, make suggestions for enhancements to the user experience, raise performance expectations. There are more broken windows out there, in other aspects of the software, we’re working hard to mend them.

No related posts.