You are here


Agile software development and the broken window theory

Development process

Agile software development is broken down into a usual set of core phases – designing, coding, testing and demonstrating progress. At any of those stages, adjustments are made to either the business logic or the source code – pending questions are answered and common code paths are merged and rewritten.

But quite often, the developers and testers notice something isn’t right – sometimes they are small things such as variables names or format of the logged messages, but in other instances the issues are more fundamental – ex. protocol shortcomings, future extensibility. And what actions are taken depends heavily on the culture within the engineering team, and the emphasis on engineering is very crucial.

Software development is still in the process of establishing its own identity and differs greatly between companies and the products they deliver. Cloud based products allow companies to focus on early delivery and reducing the mean time to repair minor issues that can be easily fixed with fast and battle tested deployment processes. On the other side of the coin, products delivered directly to their users require an approach directly related to classic engineering methodologies – very strict rules, clearly defined processes and direct responsibility of people in charge.

In the engineering world of building houses, it is clear that nobody would feel comfortable with architects widening the walls in their house because there is a risk of everything collapsing. You can easily compare this analogy to the upgrade of the storage engine that invalidates previously collected data.

On-premises software

Installation of any complex system is a non-trivial exercise because at times, they become irreplaceable parts of the internal infrastructure. Maintenance windows, formal change requests policies and off-line systems raise the cost of software upgrades.

This is why one of the most important criteria when selecting the software vendor is their proven track record of delivering quality products. Consumers of the software put their trust in the hands of the vendor.

Software installed on-premises tends to get integrated more tightly with the other systems and its stability becomes even more significant. 

Quality assurance

Assuring the quality of developed software is an ongoing process which starts at the early stages of design. Writing code in its early stages is all about making conscious decisions on how to structure the code, how to combine common functionality and, with knowledge of future features, making sure that they can be added with minimum effort.

During initial development testing, the functionality is validated and any shortcomings are fixed instantly. How much effort is dedicated to this type of testing again depends on the scope of changes and the trade-off between developer's time and tester's time. For obvious reasons, dedicated testers act as the gatekeepers of the quality.

Early delivery of usable components for the proper testing is highly beneficial as the feedback loop is shorter and any issues are identified quickly. 

Broken windows

The broken window theory is a criminological theory of the norm-setting and signalling effect of urban disorder – or in short, leaving unfixed problems for later tends to accumulate problems beyond the point of repair.

In software development, we tend to use the term of 'technical debt' and very often the management (like many governments) decide to leave the re-payments to the future generations. While in some cases it is a very reasonable approach, it is a dangerous path if left untracked.

In teams of any size, the similar functionality is being built and quite often it is based on components already built by somebody else.

Unfixed problems get repeated.

Testing sometimes is deferred until a full featured service is delivered. But during that time, some of the code can be re-used, re-formatted, the location of the configuration files is replicated, or any other duplication may occur. 

Unfixed problems get repeated.

Opsview's commitment

At Opsview, we encourage everyone to wave the flag and raise any issue noticed during development or testing, no matter their severity.

We are committed in our efforts to fix every known problem as soon as possible because leaving unfixed problems for the future is against our values. We are proud of our proven record of smooth upgrades and the feedback we receive from our existing customers is what makes us proud.

(Also, because once we finish something, we want the job to be completely finished in order to increase our own efficiency, save the valuable time of our hard working team, and ensure that our next slate of innovative releases is not slowed down!) 


Get unified insight into your IT operations with Opsview Monitor

aburzynski's picture
by Alex Burzynski,
Product Architect
Alex is responsible for the invisible parts that make Opsview work - designing, implementing and improving our back-end architecture and the growing pool of (sometimes misbehaving!) daemon processes. Alex is very impatient and expects nothing less than perfection from his team. While not working on the next generation of Opsview, Alex monitors the minimum amount of sleep needed to stay alive.

More like this

DevOps in Desperation - Did Someone Say Ansible?
Apr 12, 2018
By John Jainschigg, Technical Content Marketing Manager

So, last Friday night, I decided to turn my infrastructure into code by learning Ansible, and capture the entire demo configuration, so that, in...

Bill Bauman introduces Opsview WSLTools at Monitorama PDX 2018
Jun 15, 2018
By John Jainschigg, Technical Content Marketing Manager

Monitorama PDX 2018, in Portland, offered an intense, three-day conference program -- by and for monitoring and DevOps practitioners.  

CobWeb Cloud Solutions
Jun 29, 2016
Case studies
By Eric Bernsen, Marketing Analyst

Cobweb is a cloud services specialist and the largest hosted Exchange provider in Europe. As a leading cloud communications provider, Cobweb’s...