By now, even with my own limited reflective powers, I was starting to see troubling patterns across all of the development projects in which I had been involved.
Was I a jinx? After all, most of the projects I had been on never really amounted to much, and those that did were very murky and unsatisfying compared to what I imagined they could potentially have been. Maybe I was the problem – maybe the projects would have been great successes if I hadn't been their to mess them up. Or maybe I had just been unlucky, and all my projects were atypical. Or maybe, just maybe, I was waking up to the sobering reality that most software projects are far less pleasant on the inside than they appear from the outside. I decided I need to investigate.
I left the bank, and went back to University to pursue a PhD – I wanted to immerse myself in understanding where things were going wrong. Now, most folks in the department turned out to be working on things far removed from “real life” - they were investigating parallel garbage collection schemes for Haskell, and the like.
Thankfully, my own supervisor (Stuart Kent – now at Microsoft) turned out to be a wonderfully practical man. We spent oodles of time researching modeling notations, software architectures, design patterns, and all sorts of interesting things. My PhD ended up exploring why and how software architectures decay over time resulting in fragile systems that people were afraid to change – it even offered a field-proven solution, taking a agile refactoring-driven approach to restoring adaptability. Importantly, my research advocated a reflective process, wherein the development team monitors customer satisfaction and adapts the process according.
It was great – I felt that I now understood lots more about the theories underpinning software development, and what can go wrong. With my new PhD in hand, I was ready to return to in-the-trenches software development and apply my adaptive process in the real world.