Reading through all of the Agile 2014 tweets, my memory flipped back to my university years where I consider the seeds of Agile were sown. Although I am sure people at that time didn’t think that was the CASE. (pun intended)
I was taking my Advanced System Analysis course and the final chapter was on CASE tools. If you want a refresher, the wikipedia page is actually quite good.
I remember at that time in the late 80’s there was major discussion/movement on code generation and CASE tools. I guess it was the professions response to all the challenges with Software Development at that time. We had challenges completing projects successfully and within our estimates, so the CASE tools were going to ride to the rescue and generate all the code once we got all the requirements specified. In that way we would remove all the challenges and problems with the troublesome development activities. Which I guess were identified as the problem. If anything, this was the last gasp of the big requirements up front movement. If anything, these CASE tools required even more detailed requirements up front than were required before. A proliferation of modeling tools arose out of this movement to greater and lesser degrees of success. But thankfully none of these tools really provided an answer to the problems.
In my limited use of CASE tools, I was amazed with the amount of work required to define the requirements to be able to generate code. And then it seemed that unless the code was totally mundane, there would always be issues with the code. And don’t get me started on the performance of the code.
What I thought was interesting was that I saw two solutions arise out of the CASE rubble.
1) Off-Shoring – In the spirit of sub-optimization, this solution followed in line. If we can’t design tools to generate the code automatically, lets figure out a way to ship the code creation to the cheapest possible resources. In many ways, this was a solution in-line with the principles of CASE. We need to create a detailed specification document that we can then take and generate code from, either by algorithm or people.
2) Agile – although we didn’t call it Agile at the time, the other movement that arose was a recognition that sub-optimizing the development activities was the wrong approach. What we needed was an integrated, cross-functional team, not more requirement documents. We also needed to deliver more frequently to the end client and work side by side with them. This was the absolute opposite of what was typically envisioned with the CASE solutions. In hindsight, I really feel that this was the start of many of the flavours of Agile. (although they wouldn’t officially should up on the scene until years later)
What I find most interesting is when I look back, the CASE movement was all about trying to solve a problem with more and more technology. Which we know hardly ever works. Now there is additional technology that makes Agile solutions possible, but at its heart it is a system with less technology not more. It is about communicating and working together to solve a business problem. Whether we be business people, analysts, developers, or yes, even project managers.
If I only had the foresight back them to buy stock in 3M for all the stickies that the industry would successfully use over the next decades, I would be a rich man.
Rest in Peace CASE, Long Live Agile.