It seems that mainframe ("Dinosaur") development practices are so far removed from "more modern" language and technology development that they are practically different careers.
Or at least, I used to think so...
A couple of years ago, my employer ran a "Developers' Conference", as a place where the company's developers could gather to listen to keynotes by our technology leaders, on topics ranging from specific overviews of particular areas of our technology to general visions of the future of technology in our company and industry. It didn't take long to figure out that the conference was aimed squarely at the Java community within my company, but the invitation was open to all, and here I was, with a handful of other mainframe COBOL developers who were motivated enough to attend.
The conference was a real eye-opener, and not just for introducing me to terms like 'wiki', 'mash-up' and 'Flikr' (I'd been seriously sheltered in my career to that point). It made me realise I'd been in a career rut, and led me to become dissatisfied with the toolset I'd become comfortable with over the past 15 years of mainframe development.
It started with one of the keynotes that attracted my eye. Titled, 'The Future of Development at (my employer)', the content didn't really focus much on the future, but more on the problems with the way that we currently do development (and this was talking about the Java side of things, not the mainframe side of things - though just as relevant to mainframe). One almost throw-away line from the keynote went something like "By the way, if you haven't read 'The Pragmatic Programmer', you should!". That stuck with me, and not long after, I found myself thinking about what to read next, and came back to this book. I found a copy in a local bookstore and started reading. Wow!
Many of the concepts in 'The Pragmatic Programmer' are not aimed at development on mainframes with limited command-line capabilities, and in static languages like COBOL. However, a surprising amount of the ideas in the book relate directly to ANY kind of development - not just the 'popular' or 'modern' languages. Many of them don't even relate directly to development - more to improving yourself as a developer - the book is afterall, subtitled 'From Journeyman to Master'.
A surprising thing started to happen as I read through this book. I started to think about each of the concepts presented, and in many cases, my mindset shifted from "this doesn't apply to me", to "well, why not?". Just because, for example, there is no framework for automated Unit Testing on the mainframe, why should that mean that I as a developer cannot use at least some of the techniques of Test Driven Design? For that matter, why couldn't I as a developer start to develop a mainframe framework for automated Unit Testing?
The bottom line is that just because the 'mainstream' developer community doesn't seem to think much of mainframe / COBOL development, and though we don't have a particularly sophisticated toolset readily available for implementing many of the modern (or "Agile") development techniques, this doesn't mean that we can't all at least aspire to work in better ways.
Within the constraints of our toolset, we can still work smart. We have the same brain capacity as the non-mainframe community. We can apply 'modern lessons', 'modern techniques', 'modern design patterns' to our everyday work. Admittedly you can only take this so far - some Object Oriented design patterns just can't stretch to a static language like COBOL or Assembler. But, plenty of concepts DO work. 'Don't Repeat Yourself...', 'Don't leave broken windows...', 'Automate what you can...' - these things are universal and just as relevant to mainframe development as to web development or PC development.
We also can't afford to neglect our own intellectual property, just because the systems we maintain are 15 years old and the technologies we use to maintain them haven't shifted in that time. Keeping up with the latest ideas and reading technology magazines and blogs is valuable, regardless of what technology we work in.
Possibly the hardest part of the problem though, is breaking out of our 'Dinosaur' mindset in the first place.
No comments:
Post a Comment