Recycled Bullsh-IT

Over thirty years ago (in 1986 for future readers) I was sat in a small room in a mining company’s office in Windhoek, Namibia.  In front of me was an IBM PC-XT running MS-DOS with a CGA monitor.  I was there to develop a Purchasing Contract Control System.  In 4 weeks. On my own.

I was there because a couple of months before I had presented at a worldwide mining conference on 4GLs and Prototyping, and how they would revolutionise software development.  Not many people got what I was saying, but one guy came to me and said he was looking for a new procurement system and his IT department had quoted him 12 months and a seven figure sum to develop this on their mainframe in Adabas/Natural.  Could I help him?

Back in this small room I was two weeks into the four weeks I had estimated.  Every morning I had a 30 min session with the business users to show them what I had developed the previous day, and they would play with it, tell me stuff they had forgotten to mention before and suggest some improvements.  I would then spend the rest of the day developing the database, screens and reports they wanted.  I was using a 4GL called PROIV that was a form-based tool for building IT systems quickly. 

In the present day I would be obviously following an agile approach, within a timeboxed scrum framework, doing daily sprints and sprint reviews.  In those days we called it prototyping, but the approach would change its name regularly, like a dodgy cold-calling company, through RIPP, (Rapid Iterative Production Prototyping), RAD (Rapid Application Development), DSDM, to its current manifestation of Agile.  So the name has changed to protect the guilty (me included) who promised a new world, and mainly delivered disappointment.  Has anything else changed?

From my grey beard stroking perspective, not a lot is different.  The early lessons us pioneers learnt the hard way are still being learnt from the shiny eyed newbies hacking code today.  To assist/confuse the next generation, here is my view of the lost gospel of the Agile bible:

“For many are called, but few are chosen”

True agile is not for the masses.  It takes an uncommon mix of technical brilliance, the stamina of a goat, telepathic communication skills, and problem solving mentality to make it really sing.  Don’t try this if you are a plain mortal.

And there is salvation in no one else, for there is no other name under heaven given among men by which we must be saved.”

 Or, if you only have a hammer, you tend to see every problem as a nail.  Agile cannot solve all software challenges.  Anyone who says they can has a special circle of Hell waiting for them.  Agile delivers best for small, simple, defined, self-contained problems or requirements whose outcome is clear and whose sponsor is driving for success.

“For in six days the Lord made heaven and earth, the sea, and all that is in them, and rested on the seventh day.”

If it can’t be delivered quickly (maybe up to three weeks, not always one), then your chances of success will rapidly diminish.  And if you need more than a day’s rest, you are obviously too mortal to succeed anyway.

“You cannot see my face, for man shall not see me and live.”

A major cause of failure and disappoint on agile projects is lack of face time with the users and sponsors.  They may well be too busy to meet daily with you, but if it isn’t important enough for them to be poking you every day you should down tools and find something more worthwhile.

“Assemble, all of you, and listen! Who among them has declared these things?”

In an increasingly connected Internet of Things, building standalone simple systems is rare.  Even with better API tools, sockets and IoT frameworks, ‘plug ‘n’ play’ is still a pipedream.

“Peace be within your walls and security within your towers!”

If it wasn’t for those pesky security policies and data protection laws, our job would be a lot easier.  Conversely, building quickly and securely requires significant planning and expertise that even the Avengers would struggle to assemble.  My biggest security headaches are with newbie-developed systems that don’t get enough security- or test-driven development emphasis.

For those at all interested in how my historical tale ended: The working prototype was delivered and used by the procurement team at the end of the four weeks.  I went back for a second phase a few months later to discover that their ludd-IT-e department had refused to support the new system, so they ended up on the mainframe after all.  However, a few years later as spreadsheets started to take off, we re-wrote it in Excel which procurement could look after by themselves.  And started the end-user development revolution which haunts IT departments to this day.  But that’s a horror story for another day…

John ‘30 years of hurt, never stopped me dreaming’ Moe