OSS Watch recently ran the second Open Source Junction a series of events connecting industry and academic innovation in open source mobile technologies. The event series seeks to make these connections through software developers.
Stephen Walli, the Technical Director of the Outercurve Foundation attended both events and, during the internal evaluation phase in which OSS Watch consider how to improve the next event Stephen kindly took the time to provide some really valuable feedback. This post attempts to encapsulate this feedback and frame it in the context of the work OSS Watch are doing, alongside others in the sector. I’d like to thank Stephen for giving me permission to quote large sections of his emails to the OSS Watch team.
Good software is developed by good software developers. It involves a discipline not found in most developers. Rigorous version and config management, checklist for style and review, desk checking reviews before commits, automated builds, fully automated tests are all necessary steps to successfully, reliably delivering binaries that work, and most importantly when a binary fails you know exactly how you created it from what tool chain (and conceivably what version of the tool chain) and source using what version of the recipe so you can reliably rebuild the failure and fix both it and the test environment. Great developers may be great architects, but every great developer is a good disciplined developer first, and they really don’t know how to build software otherwise.
Personally I couldn’t agree more. I have long argued that we suffer from a significant lack of good software development discipline. As my Software Engineering lecturer told me, far too many years ago, “I’m not going to teach you to build software systems. Even a modest software system is as complex as a small town. I’m going to teach you how to make a dog kennel, or if you are really good a shed, we don’t have time for more than that.”
I, like most students, was taught the waterfall method of software development, a method that wasn’t in common use when I was a student and is in even less use now. Furthermore, most students leave University without any knowledge of version control, testing, continuous integration, build tools, issue tracking or any of the other disciplines Stephen wants to see in a good developer.
In general most students graduating from university have been taught how to build a kennel and are unaware that to build a tower block they need cranes, forklifts, jack-hammers and many other tools. These are the tools that we have to learn about when entering our first real software development team. In such teams, if we’re lucky, there will be one or more developers who understand the importance of the correct tooling, rigour and discipline in software engineering.
I’ve been fortunate enough across the ~25 years I was around software development projects (IT) and products (ISV) to always have at least 10% of the organization and sometimes as high as 30% be such good developers. The rest of the team had an easy time contributing appropriately because of the culture at the top set by the few. We all know what needs to be done — just few of us do it.
Stephen goes on to observe that he is not one of these developers. Sure he can develop software, he knows how to use the tools and he knows the discipline needed in good software projects, but he looks to others to enforce the necessary discipline on his work, and that of others (for the record, so do I).
Without such discipline at the top, I believe no project can succeed regardless of whether it’s academic, IT, or government. This is why Apache and Eclipse and Linux have such well defined and documented engineering disciplines around them, and why they succeed.
I’m lucky enough to have worked with Scott Wilson at CETIS on the Apache Wookie (Incubating) project. Scott is a visionary and he loves to understand and work with open standards. Like me he loves to bring people together and get them to collaborate, this makes him the visible driver of the Wookie project. I’m there to mentor the team in the Apache Way, to ensure they understand what needs to be done. However, neither of us are the ones who are moving Wookie towards being a truly great software project. A project that is attracting commercial engagement. Sure, we have our strengths, but neither of us are the disciplined software engineer needed to ensure the success of the software itself (which is different to the success of the concept hawked by Scott).
Over beer the other day Scott and I were both happy to sing the praises of Paul Sharples on the Wookie team. Without Paul and his rigorous attention to detail Wookie would not be on the verge of it’s first official Apache release. Without Paul we would not have the rigour needed to go through the various IP and quality control processes of a good open source software project. Without Paul, Scott and I would probably be telling everyone how great it is whilst gradually making the code decay with our endless hacks.
Scott and I raised our glasses to Paul and all the good software developers out there. It is my hope, and I believe that of Stephen’s, that OSS Watch will continue to seek out teams that have a “Paul” in them as well as a “Scott”, through those teams we can create true academia-industry links that will benefit all.