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.

Dear Dr. Yeahbut …

We have too many meetings.

I’m sure I’m not the first person to gripe about this, but if I’m not, why does it keep on happening? More important, what can I do about it? I need to do actual work, but easily half of every week goes into meetings. Help!

– Burnt

Dear Burnt …

Not all meetings are created equal, so there’s no one answer. In even numbers there are four types of meeting: Status, decision-making, information-sharing, and team working sessions. One at a time:

Status Meetings

These are weekly meetings of project team members and only project team members. Each team member reports on whether the tasks they were supposed to start started, the tasks they were supposed to finish actually finished, and, if not, what their plan is to get back on track.

Project status meetings are essential project-management tools. No, they aren’t an efficient way to collect task status information for the PM’s project status reports. They’re essential because they’re the most effective way to apply peer pressure to sub-par-performing team members.

If you’re on the invitation list for more than two weekly status meetings the problem isn’t that you have too many meetings. It’s that you’re assigned to too many projects. That’s an even harder problem to solve, but it’s a different problem.

Get out of meetings free card: You don’t get one. Project status meetings aren’t optional, even for team members who started and finished their tasks on time. These team members are, after all, the ones that exert the most and most effective peer pressure.

Decision-making meetings

There are, you might recall, five ways to make a decision: Authoritarian (I make it); Consultative (I collect informed opinions before making it); Consensus (we don’t all agree with the decision but do all agree to it); Democratic (we vote, the majority wins, and the minority pretends to accept it); and Delegated (someone else gets to make it).

Of these, the only decision style that calls for a meeting is consensus – the most expensive way to make decisions, delivering the second-lowest-quality results (voting is even worse). For most decisions, consultation strikes the best balance between quality and efficiency. Leaders should make it their go-to, reserving consensus for situations where stakeholder buy-in matters more than anything else.

Get out of meetings free card: If it’s your meeting, don’t have it. Consult or delegate the decision instead.

If you’re one of the invitees, politely decline the invitation and suggest a 15-minute one-on-one consultative call instead.

Information-sharing meetings

When managers were less buffeted by information, the conveners of information-sharing meetings asked, “Who needs to know about this?”

As most managers are buried in information, this quaint notion from days gone by has, or at least should have been supplanted by a different question: “Who can’t function effectively without this information?”

One more point about information-sharing meetings: Attendees are prone to try to turn them into decision-making meetings, on the grounds that “Why are you telling me this if you don’t want my opinion about it?”

Get out of meetings free card: If you’re the convener, ask yourself what it is about this information that requires a meeting and not just an internal blog post with a comments section for any back-and-forth that’s called for.

If you’re on the invitation list, ask if you won’t end up just as well informed by reading the meeting notes.

Team working sessions

Well, if the team really is getting work done then this counts as time you’re spending getting work done.

Get out of meetings free card: Even when teams met in 3D in a whiteboard-equipped room, working sessions should have been limited to seven participants. Limit web-conferenced meetings to five. If you’re the convener, adhere to these limits. If you’re invited and don’t need to add your voice to the proceedings, brief another participant … one you trust … with your perspective, and let the convener know you’ll accept the results.

Bob’s last word: Layered on top of this brief meeting taxonomy is a meta-purpose, which is that meetings are where team members get to know each other, building trust and shared purpose as they do.

Getting work done is transactional. It’s what can be tracked, and what pays the bills.

But relationships do matter. Leaders who ignore them find the teams they lead gradually enter a long, slow slide into dysfunction.

So along with discontinuing meetings that shouldn’t ever be scheduled, wise leaders find ways to replace their relationship-management meta-purpose.