All Posts in Policies and Procedures

|In: App Dev Methodologies|Last Updated:

In the beginning there was dBase II, designated “II” by Ashton-Tate, its publisher, to convey a level of maturity beyond its actual virtues. It was followed in quick succession by Paradox, Delphi, and Microsoft Access, all of which overcame most of dBase II’s (and III’s, and especially IV’s) numerous limitations.

Compared to traditional programming languages these platforms increased developer productivity by approximately 10,000% compared to traditional COBOL coding – they let me get about a day’s worth of COBOL coding in five minutes or so.

This history was current events more than twenty years ago and yet IT shops still write code and enshrine the practice with various methodologies (Scrum, Kanban, DevOps, add-your-favorite-here) intended to improve IT’s overall app dev effectiveness.

Speaking of deja vu, the pundits who track such things write about no-code/low-code (NC/LC) development environments as if they’re something new and different – vuja de, like nothing they’ve seen before – when in fact they offer little their 1990s-vintage predecessors weren’t capable of way back when.

Should NCLC be in your future? Gartner says yes, predicting that by 2024, “… low-code application development will be responsible for more than 65% of application development activity.”

They make it so easy … to nitpick, is that 65% of all lines of code that will be produced using No Code tools? Probably not, as No Code tools by definition produce no code.

Function points? Maybe, except that nobody uses function points any more.

Probably, Gartner means 65% of all developer hours will be spent using NC/LC tools.

Which is simply wrong, on the grounds that most IT shops license when they can and only build when they have to. In my unscientific experience, looking at total application functionality as the metric, maybe 75% comes from COTS implementations (commercial, off-the-shelf software, which includes but isn’t limited to SaaS packages). Maybe 25% comes from in-house-developed custom applications, and that’s being generous.

As NC/LC platforms don’t touch COTS/SaaS functionality, it’s doubtful that work on 25% of the application portfolio can occupy 65% of all developer hours.

But I digress. The question isn’t whether Gartner has done it again. The question is how much attention IT should pay to this platform category.

Answer: If coding and unit testing are enough of a development bottleneck to care about, then yes. When it comes to optimizing any function, removing bottlenecks is generally a good idea.

Second answer: If in your company DIY application development is a source of a lot of application functionality, then selecting an NC/LC standard, integrating it with your application portfolio’s systems-of-record APIs, and providing training in its use will save everyone involved from a lot of headaches, while removing a source of friction and conflict between IT and the rest of the business.

Third answer: Most COTS/SaaS applications have some sort of no-code or low-code toolkit built into them. These should be IT’s starting point for moving in the NC/LC direction, and for that matter for any new application functionality.

Bob’s last word: It’s easy to fall into the trap of answering the question someone asks. “Are NC/LC tools useful and ready for prime time?” is an example, and shows why Dr. Yeahbut makes frequent appearances in this space.

The answer to the question is, in fact, “Yeah, but.” NC/LC development should, I think, be part of the IT app dev toolkit. But mastering the tools needed to integrate, configure, enhance, and extend the company’s COTS application suites has, for most IT organizations, far more impact on overall IT app dev effectiveness than anything in the way of app dev tools.

Bob’s sales pitch: As a member of the KJR community you might enjoy my most recent contribution to CIO.com, and a podcast I was interviewed for.

The CIO.com article is titled “The hard truth about business-IT alignment.” You’ll find it here.

The interview was for Greg Mader’s Open and Resilient podcast and covered a number of KJR sorts of topics. You’ll find it here.

Comments

|In: Shadow IT|Last Updated:

Professionals like do-it-yourselfers. Undoing a bad job and replacing it with a good one is, after all, more profitable than starting from scratch.

Not that all do-it-yourselfers are hopeless (or, for that matter, hapless). The trick for those of us who engage in DIY is knowing when a new project is a reasonable stretch and when our daydreams of the perfect installation crash into a needed skill that, like soldering copper pipes with a blowtorch, is just too terrifying to contemplate.

Add to that an entire industry devoted to making DIY projects less daunting — a recent successful adventure with digital door locks comes to mind — and the equation becomes more interesting.

This being KJR we aren’t, of course, talking about home improvement. We’re talking about office improvement through the deployment of so-called “shadow IT.” One difference … no analogy is perfect, after all … is that unlike home improvement failures, where professional plumbers, electricians, and dry wallers are happy to get paid for fixing someone else’s mistakes, IT professionals aren’t usually too thrilled when they’re called in to deal with DIY software gone wrong.

Which isn’t to say trying to stomp out shadow IT is a good idea, any more than trying to stomp out DIY home improvement would be a good idea.

As is so often the case, good policy starts by recognizing that different groups have different priorities.

With home improvement, the goals for a typical DIYer (aka me) are, in descending order of importance, (1) saving money; (2) getting a warm feeling of accomplishment; and (3) receiving admiring compliments from friends and family.

Home improvement professionals, in contrast, most likely want: (1) profitable income; (2) repeat business; and (3) referrals.

Software DIY? My informal experience tells me the DIYer’s goals are quite parallel — to get: (1) the benefits of automation sooner rather than later; (2) a solution that’s tailored to fit the situation without having to explain what’s needed in detail; (3) admiring compliments and all that.

IT’s goals when implementing software are a bit different. In particular, IT wants (1) easy and maintainable integration; (2) solutions and the platforms they’re built on that aren’t going to vanish from the technology marketplace, provided by (3) vendors that also aren’t going to vanish from the landscape; and, oh, by the way, that (4) do enough of what business requesters want that they can live with the gap, without demanding a lot of tailoring or customization.

That’s quite a mismatch. But the mismatch between DIY IT and IT-led implementations isn’t a problem. It’s a place to start.

Bob’s last word: That two groups have different goals isn’t an insurmountable problem … unless, that is, the groups have no interest in achieving any goals other than their own.

What we typically have is mutual distrust and fault-finding. What we need is a methodology that accommodates both IT’s and business DIYers goals.

Bob’s sales pitch: It doesn’t address this issue specifically, but I think you’ll find chapters 4 and 5 of the KJR Manifesto helpful, and not just for dealing with shadow IT.

They’ll help any time addressing two groups’ distrust is where you need to start.

Comments