During SoCraTes France we had a session called Beyond Alchemy and What are the Software Leprechauns? with Laurent Bossavit, author of The Leprechauns of Software Engineering. We discussed about what we could do, as a community of professional developers, to raise the bar of our industry by starting to merge the scientific method used by academics and the huge amount of data from the real world of the industry.
The idea of this session was inspired by a discussion started some time ago on the Software Craftsmanship Slack with Alexandru Bolboaca, and then he wrote a great article on his blog: Three Problems For The Next Era of Software Craftsmanship. Three challenges that we, as a community of developers, could try to solve to raise the bar of our industry: 1. Eradicate legacy code 2. Raise the standard of proof 3. Educate the next generation on real world software development techniques
Uncle Bob always talks about - and I agree with him - the idea of a real Profession of Software Development, as doctors or lawyers have. But what are the roots of a real Profession? What is the difference that is still there between the making of software and the other professions?
A Profession is based on measurements
Other professions focused on their practices and they measured their progresses. Doctors historically have documented every aspect of what they have been doing in order to improve their profession, and once they had a set of objective, well documented, measured and tested practices, they put ethics rules on top. The Profession started. They now have a set of rules and practices that they all follow. They are teached at school and they are continuously improved by the community working closely with Science and data (and those who don’t follow them are expelled).
Alchemy and Reinventing the Wheel
In Software Engineering we still behave like in Alchemy. We try things, sometimes they work, sometimes they don’t. We never really measure them. We create technology on top of technology and we switch from one technical choice to another, sometimes based on our guts or wrong assumptions. We advocate for technologies or methodologies, but we don’t have empirical data to really sustain our arguments. We still write legacy code despite all the books, talks and failures of the past. We still have religious fights between technical choices that could be measured instead. We still have to sell to the management that spending time on testing is good for the business. Computer Science courses still don’t tech books like Clean Code or Refactoring (maybe only very few cases in the world). The education of the next real world software engineers is still left to their practical exprience at work, we are not using the experience from the industry to make education grow.
The distance between the real industry and academics is still so long. There are many scientific papers and excellent researchers on Empirical Software Engineering, but their problem is that they still miss enough data to come to shared and definitive conclusions.
Despite all the technological changes and incredible improvements of the last decades, we are still reinventing the wheel over and over again when it comes to our development practices.
Open our data to the community
During SoCraTes France we discussed about this. What if we could start to measure what we do? What if we could start to fill this gap between the scientific method and the choices we make in our industry? What if we could provide enough empirical data so that willing people or researchers, on day, could use them and come up with new ideas, theories or conclusion? What if we could open the huge amount of data from everything we do when we write software with the community, and finally start to grow as a Profession?
During SoCraTes France Laurent Bossavit mentioned the idea of a database of information about bugs. Information that could tell us everything about how these bugs were created. Info like the programming language used, how many people in the teams were involved, what was the error which caused the bug, did they work in Scrum/XP, did they do TDD or not, etc…it was just an idea thrown quickly during the discussion, but it could be an interesting path to follow that could be source of many different statistics.
What we would need is a way to make these data available for everyone for free. We need professional developers willing to help by providing generic and anonymous data about their practices, their methodologies and the tecnologies they use. We need a platform able to collect these data and make them available for everyone. And we need these data to be sent possibly hassle-free for the developers. We need people with knowledge about how to set up scientific test cases in order to know which kind of data we would need. We need lots of things.
We are in the core of the technology era, we have to start to measure how we work.
We need to formalize our practices based on empirical data that can show us what’s working and what’s not. We need to stop religious fights with technologies.
We have to grow based on measurements and Science.