There are many definitions of bad software. Clean Code’s metric of WTF’s per minute, test coverage, cyclomatic complexity, and a million other measures can be put in place to measure good vs. bad software. Through the lens of Agile Congruence I want to offer yet another definition of bad software.
Bad software is software that changes slower than your organization.
In an organizational change process, you will encounter a lot of resistance to change. Organizational structure changes require buy in from many stakeholders. Culture changes require discipline of your team. People changes require a willingness to learn new skills. If your biggest impediment to changing your organization is that your software team says that the delivery of the required features is too difficult, you have bad software. All development organizations have technical debt. This debt needs to be managed and invested in to allow your organization to have the speed and flexibility to change.
I have seen some brilliantly coded software that was written by great engineers that did not improve organizational efficiency at all. Releasing enterprise software will change your organization, but it is not guaranteed that this will be a change for the better. Without achieving congruence, you should not expect software to solve your organizational problems.
Taking an iterative approach focused on people, collaboration, and user feedback and making small changes not only makes your development organization agile but by using the Agile Congruence framework it can extend to make your whole organization agile and ultimately more effective.
Leave a Reply