This blog tells a short story about what can happen when we focus too much on a detailed solution to a specific problem – while time moves on.
An Age-Old Problem
That specific problem dates way back to the late 80’s, when I was leading a Software Development Team in the German Army. Every 3 months I had my pick to get 1 or 2 new team members from a batch of bright-eyed albeit inexperienced young people to turn them into COBOL (of all things!) programmers. Of course, in turn I had to let 1-2 of my current team go; their time with the army was up. So I waded through lines and lines of code to get the new guys started where the old ones left up.
Of course, everyone had their own style of coding, and (more or less) documenting, and there was a lot of time wasted trying to make sense of it all.
Turn the page… Years later, as ABAP Lead with an SAP consulting company, every time I had some new developers coming in, guess what… same procedure. So I did what all of us did back in those days. Established the dreaded ‘Documentation Guidelines’ and forced my poor guys to spend a good portion of their time writing up stuff about their work. Which they did, more or less.
Nowadays, as an ABAP Freelancer, coming into a new client project – time is money, and what happens? First of all, I have to dig through whole labyrinths of code to find my way to my new build site. Comments? Documentation? Well… you know.
A Nice Try
Some things never change; and I wished there is a way to automate that kind of busywork – in a way that makes sense for the reader and does not depend (too much!) on the Developer / Author. Nothing against things like ABAP Doc – but still, the developer has to spend some effort to make comments, and talk about their work…
But wait: Does not, by definition, the Development Object (and it’s runtime environment; technically speaking…) contain all the information it needs to run? The developer just put it there! (And according to the 1st Law of Thermodynamics it cannot get lost… unless we’re beyond the Event Horizon of a Black Hole ?). So it is only a matter of getting it out of there.
So I made some time, sat back thinking, and came up with a design for a tool that analyzes the Development Object itself (source code, metadata, structure, and yes, even including comments if they exist) and create a Technical Document that I thought I could use to at least gain an initial understanding of what I’m up against, when I see an unknown program (or Class, or Transaction…) for the first time.
Then I made some more time, got down to business, locked myself in and started building. Without looking left or right, and never bothered wasting time to chase the latest trends in technology. When I finally had something halfway workable, I looked up and stepped out of what I now realized was some sort of a nasty Time Machine… Years had passed, and my prototype is now all but obsolete.
I had built a ‘Better CD-Player’ and brought it into a world where everyone is streaming music… ?
Food for Thoughts
Now, what do we learn from that little story? Several things come to mind:
Inventing nowadays is just for large teams and companies with the money and manpower to keep up with evolving technology. Hm… not a nice thought.
Due to recent improvements in tools and techniques, such as ABAP Doc, ‘Clean Code’, GitHub and so on the root problem has gone away. Really?
I just did not do a good enough job nailing down the requirements and designing / building the solution. Kinda embarrassing – but, well, nobody is perfect.