Clif Notes: New Blood Part 4
Recap
In the previous three parts of this series we've talked about the need to attract developers from the "Millennials" in order for the MultiValue database to survive. Part one discussed the problems we, as the MultiValue Community, create for ourselves when we don't think before we post in public forums: The damage done by MultiValue developers when acrimoniously airing our own opinions — supported by facts or not — about what isn't right about this MV thing. In part two, we went on to explore a bit about what it takes for an IT shop to attract Millennial-aged developers and what it takes to keep them.
Part three was probably the most likely to cause roars of disapproval and outrage. Frankly, it is a topic that I've been on about for years now and still causes traditional MultiValue developers to grab torches, tar buckets, and chicken feathers and head in my direction. I'm talking about the extremely simple expedient of not coding in all uppercase like the 1960s and '70s. The style has changed and we need to change with it.
Onward
Well, this final part in the series shouldn't be as "personal" a challenge since many of the things we will touch on are not currently being done in most MultiValue shops. That's not to say that they will be accepted. After all, the attitude of "we don't do things like that because MultiValue doesn't have to" is the usual comeback from the Cowboy Coders. But they aren't the ones who are making the company decisions and writing the checks that pay our salaries, consulting invoices, license fees for vertical applications, etc. If you weren't at the opening of this year's (2015) International Spectrum conference, you might want to sit down. This might come as a bit of a shock to you other old-timers (I include myself, and it was).
Nathan pointed out that depending on what birth date range you use to define that vague "Millennials" term, "The Millennials are Coming!" is no longer true.
The Millennials are already here , folks. They are quickly moving up into IT management. They'll be making the decisions about which databases, which tools, which developers the company is going to spend money on. And what gets thrown on the garbage heap.
Question: What's the "Right Way" to develop software?
Answer: The way the 32-year-old dude(tte) who is one, two, or more levels above you in the org chart says.
What does their idea of a modern development shop look like? It varies. But in most cases it contains a mix of the following trends.
Use of Modern Tools
Got news for some of you: The ED line editor is not a modern tool. If you aren't at least using a GUI editor (read real , not an old green-screen thing in a telnet session) you have a bulls-eye painted on you. I am absolutely stunned when I keep running across MultiValue developers still writing code with the ED editor and its variations. There are a number of great program editors out there all the way from free to "not much" in cost.
IDEs are even better. No modern developer codes, then runs, then debugs at the command line. (Though Python might be an exception. I'm still looking.) This is an area where, in my opinion, MultiValue still falls extremely short. It's getting better with some of the platform enhancements and third-party products, though. More on that in a technical article, I think.
Still doing all your reports with ENGLISH/RetrieVe/INFORM etc.? It still has its place. But Millennials expect modern reporting options. If all they see is a carry-over from the green-bar paper days, they're not going to be interested in working with it or keeping it around. Time to branch out and explore some of the other options.
The same thing holds for integrating MultiValue systems into the larger IT ecosystem of the enterprise. Too often traditional MultiValue developers haven't moved past the idea of bulk import and export of comma (or pipe or tab) separated flat files. And when the "mainstream" side of the house wants to get or send data or processing requests as XML, they are dismissed with a curt, "MultiValue doesn't do XML." (Or web services. Or JSON. Or…)
So. Tools. Get away from the TCL prompt and learn what's out there. That doesn't mean you need to learn how to call a SAX parser to process an XML document that won't fit into memory under the DOM model common in the MultiValue Basic extensions of some of the platforms. But please learn what sentences like that mean . And learn when those tools should be used. And when to call on someone else. There is no shame in knowing when to punt. Your Millennial VP will make note of that and thank you for it.
Use of Modern Methodologies
There are few MultiValue shops I've visited that have a formal testing methodology established. And by testing methodology, I am not talking about the simple, "check it out, test it, check it in" source code control — though even that is somewhat rare (but getting better, I might add). I'm talking about a catalog of established, predictable tests against a known test database with predictable results. When you don't have that, you aren't testing your changes; you're trying your changes.
So what is it that the Millennial VP expects to see (at a minimum) in a modern development shop? Why, the same thing they see in the Java, .NET, mobile web, etc. shops:
- Automated testing
- Test driven development
- Unit testing
- Code coverage
- Continuous integration
And a number of other concepts common to the Millennial developers coming out of school and submitting job applications to your Millennial boss.
"But MultiValue can't do that!"
Really? I'd suggest you go to http://intl-spectrum.com/magazine and check out the articles on those subjects in the 2014 and 2015 issues. Yes it can. And it has been done very successfully.
And don't forget about project management and development methodologies. I'm talking Agile, Scrum, Kanban, etc.
Now if you are looking for all of this to be available at no charge from the database vendor, I'm afraid you are rather out of touch. Nothing we have talked about in this series is exclusive to the MultiValue development environment (a mature product) or the database itself (mature and well proven). It's all about learning new things that tie into the MultiValue database. Or new methods that also apply to the MultiValue environment.
It is all there now. Some of it has been for years.
So what are you going to do to attract new blood to the MultiValue community?
