Finding security, complexity and maintainability issues in complex business systems, improving development team throughput, and controlling global outsourcing contracts are not easy tasks; even the best analytics on the market still leave blind spots for technical teams looking to deliver better software and prevent outages. Addressing these issues takes a pragmatic approach to developing software and a passion for coding. These issues were the basis of the Software Craftsmanship Conference, held in London October 5 and 6 and attended by CAST.
Established by Software Craftmanship, a community of 4,000 developers from the Greater London area, the conference explores the past, present and future of the Software Craftsmanship movement and how it is changing the way developers and companies think about software. Featured presentations include topics such as Test-Driven Development (TDD), Usable software design and WebOps, offered by industry leading experts, thought leaders and Software Craftspeople who shape and drive forward the craftsmanship community.
It was great to hear passionate experts talk about writing clean code and the underlying importance of writing code such that another person can easily understand it and then easily modify it. We all know that reading some else’s code can be a challenging effort, especially when unnecessary complexity has been introduced. The attendees I spoke with had a deep concern about ensuring the maintainability of their code, and that the next IT person to encounter it appreciates the software’s quality.
Too often, developers slough off software quality, rationalizing that writing unclean code is just a quick temporary fix or “I can clean it later.” As pointed out during the conference, however, “later” never comes, and the substandard quality becomes permanent as the software enters production.
These are consistent with the findings of a recent study on The State of the Modern Developer, conducted by CAST. Results of the survey, which polled 500 respondents, suggest that the use of current quality standards still leaves much to be desired. It concluded that:
These seem like obvious things to do, but too often they fall by the wayside in the interest of pushing software into production. This is why assessing software quality needs to be done from the beginning of development and throughout any changes made to it…and it needs to be done automatically.