Right-Click Coding or Clickety Click Coding
Cote, now of Redmonk, has a recent post describing what I call Clickety Click Coding and he refers to as Right-Click Coding:
I’ve never been one for model, tool, or drag-and-drop based development. Oracle development, at least as presented to us and as illustrated in the hands-on-lab (where we actually coded up EJBs and Web Services) is all three of those to the extreme. I call it ‘Right-click Coding,’ because you’re always right clicking on things to configure different wizards and properties instead of writing the code.
Unfortunately Right-Click coding does make great demos, though things like Rails are making in-roads there with command line driven demos. I despise these demos since they’re typically shown by sales engineers who never have to maintain these quick demo solutions. There’s a lot of hand waving about how you have this fully implemented domain model that allows you to just hook together all these loosely coupled services even though you’d actually have to write all those nice services in the real world.
The worst part is that they’ve invited a few business folks, who now thing all the coding is the easy part. Luckily a lot of sales engineers push inane ideas to the hilt and say the magic words, “Oh, with tool X you can just have your business analysts draw out the process.” I do a bit of cheering at this point, because those same business analysts have heard this line before. They’ve tried to use these right-click modeling tools before and they just don’t behave like Excel or Visio. Usability appears to be a very low concern for these tools which often assume you’re a developer who’s spent years in various difficult IDEs. And that’s the point business analysts get completely, “Heh, this stuff is for programmers.”
And then then there’s the other down side of relying on a tool to just generate everything:
Of course, I’m not sure how well things will go when you start having to debug and track down problems. I’m not sure there was a right-click option for ‘Fix all broken things.’
My favorite question to ask the vendor at this point is a pretty simple one,
So how do I test this?
Oh, well you can load test it for performance with something like Mercury’s LoadRunner product.
No, how do I unit test the code?
Well, your QA department can will fully test the code with a set of test cases.
But, how would I write a unit test for this?
Hmm, well the web service we just created has a client code and a simple HTML test page that you can use to test the web service.
OK, but that’s a manual integration test that tests the whole service at once, how would I just write an automated unit test.
Well, let me get back to you on that I know there’s a feature we have to cover that I just haven’t used it.
Ed Gibbs @ May 11, 2006
Well said in the end, my friend. The problem with right-click coding is that it tends to be silo-oriented. I’m sure right-click vendors. would be happy to sell you a testing suite, but getting it to work with freely downloadable suites might be more difficult.
And it assumes that there testing suite actually works or integrates with their products. Often they’ve acquired some other software product and slapped it into the suite.
If you allow, let me make a point from the vendors side.
Working the last ten years as one of these Presales Engineers above, here’s what I found:
I was working with three different models of model-based generators, two different types of whole-life-insurance suites and about 1000 sw-development projects.
Out of these 1000, I remember one (1) project that actually was able/willing NOT to touch the code and keep the whole process (at that time SA/SD) up and running. It received good project notes and great user acceptance. All others needed to redo at least part of the code, almost all had problems integrating correct and valid test automation with the generated code (if they tested).
Process is what people do and tools should help people with what they do — and not tell them to do things in a completely different way… But they also should help people become better - so some change is inevitable.
I’d like to refuse blaming only Sales Engineers and/or the vendors being solely responsible for the actual spread of the right-click-flu. For example, there might be this requirement: “I don’t wanna type/model/right-click that twice: I wrote that Requirement, why can we just have the testcase documentation generated? And that Requirement Attribute containing an expected time of reply, why can’t we just reuse it in testing? (continue at your wish: integrate A with B. A,B in [Requirements, Code, TestCases, Baselines, Defects, Signatures, etcetc])
The current tools wouldn’t sell at all, if there weren’t any benefit. As I see it, vendors aim at the general market, a.k.a. the average coder. Every tool is easily tricked and torn apart by a decent hacker:-)
The one case above was only successful, because the project team including the whole management comitted themselves to use the tool only and changed their process almost from everywhere to anywhere.
My rule of thumb:
Every tool is always half finished when you start using it. Same applies for every pre-implemented automation for your software development process…
Ah, and last thing: there are also many average Presales Engineers out, who don’t have the … to stand up and tell the truth. I hope you’ve met some of the better ones. If not: throw them the questions above (I really like these:-). IMHO, the honest answer A3 should focus on working together: “Hmm, I personally don’t know. But I also don’t know your test environment/process yet. What about we spend some time together to check that out right now?”
‘Cause that’s always the problem of every vendor technician: s/he doesn’t know you as good as you do. Help them with that and they help you where they know better: about these half ready tools (and after half a year in the job they much more tool-issues/problems/questions than you ever can imagine - if they are above the average:-)
This is a lifecycle/dogfooding thing. My suspicion about these tools is that the people that build them and sell them do not live with them - there’s more to the demoware issue than demos. IDEs by comparison don’t have that problem. They’re self-hosting.
I mean if roundtripping during the dev cycle is still unsolved, or always sold only in the “enterprise” edition, or we can’t support simple neccessary things like a test suite, there’s zero probability of things not going to hell over say, the full lifecycle.
That’s all aside fom code bloat. What does it take for these things to produce comprehensible code?
At the end of the day you always have to look at the code. A UML diagram tells me *nothing* about why my server is leaking like a sieve or is deadlocking.
I’m no luddite - if there are good codegens out there I’ll use ‘em, but imo they’re somewhat unproven tech.