UKC

Just out of interest, has anyone used the Thinkwise development tool?

My company is looking at possibly migrating a big legacy application into it.

Thoughts and experience appreciated - especially any gotchas to look out for.

Thanks,

No experience of it but do know about software development.

Some thoughts on the "low code flowcharts thing".

Just because it isn't typing in code doesn't mean that it isn't programming.

Mostly when people draw diagrams they are communicating things to people rather than trying to create a set of instructions for a computer. 

A flow chart for even a simple thing ends up massive - and could have all the problems of code (being hard to get correct and needing to change).

But I only watched a video for a few minutes and I don't know about the solution. 

The problem here is very much that it's an enormous legacy application that doesn't really lend itself to flowcharts - users could put data into a vast number of fields in any order, as it's mainly a data collection tool.

Yes, there are some places where you have to put in some data before you can put in some other data, but it's more the exception than the rule. And that doesn't even touch the myriad of integrations with other products.

Seems like you've answered your own question then. As the previous caller said it's still coding even if it's just drawing pictures and once it's done you still need people to maintain it, but then rather than having code in a well supported framework/ language you'll have it in a proprietory form hardly anyone knows and changes will be expensive. 

Only general comments.

If you can’t cut through the marketing BS and see how your legacy application fits in to it, it’s probably not the right tool…

I share Swig’s view on “graphical programming”.  The allure of simplicty and apparently lower skill barrier draws people in, but before long the limitations of the environment leave a sprawling mess that’s harder to debug, documented and maintain and harder for new people to pick up.  I have a whole “LabVIEW, know your limits” rant on the subject.

What is the current product implemented in?

What are the drivers for migrating it to a new platform?

And is likely to fizzle out as "this week's big thing".

Thanks for the comments.

We're currently going through a consultation with them about what they think they can do with it. Interestingly, one of their techies has written a conversion tool from what we currently use to their language, which "should" take away a lot of the pain.

But, as noted, we'll have it in an entirely new language that no-one here has ever used before.

This is the latest attempt at a re-write, but looks the most promising, according to management...

Are we still trying visual programming? I thought the death knell for it was in the late 1990s, except for specialist arenas. I wrote Visual FP in 1992/3, taking what is probably the tersest language I knew at the time and turning it into perhaps the most visually inefficient and challenging language to programme it. Got a first for it though...

See the work by Thomas Green and Alan Blackwell in the 1990s for all the issues of visual programming

I remember being stymied particularly by repetitive viscosity and premature commitment when programming in one visual language i tried...

https://www.researchgate.net/publication/200085937_Usability_Analysis_of_Vi...

I suppose they could always migrate to Scratch...

Do 'the management' have any actual experience of software dev and maintenance...?

I'm going to guess not...

I'm also going to guess that they think they understand the simple examples they've been given, but not the weird 'code' stuff the damned programmers write...

Says the person who once programmed gate arrays from Visio......  (To be fair, when faced with writing a lot of VHDL, I made a code generator for everything I needed using a language that wasn't VHDL...)

I'm having a kind of inversion with regards visual programming.  These days I have scripts convert various bits of code in to diagrams to give me a more visual way of checking what I've actually written against what I meant to write.  I do this more for data flow intensive stuff but also for some control segments.

Well, i didn't; my colleagues did. And that system didn't go anywhere, either...

I've only ever written raw VHDL, liking Synplify for code visualisation, which was excellent.

I do have a lot of awk scripts that generate PostScript, though...

How do you do version control on a bunch of diagrams?   I wouldn't want to be cut off from tools like git just so I could draw a pretty flow chart instead of writing if...then

Actually, I wouldn't want to draw the pretty flowchart anyway because the pretty picture is a total waste of pixels.  It is physically huge on my screen compared with the text it would replace and what I actually want is to get the whole section of code I need to think about on the screen at the same time. 

Call me prejudiced but most visual tools are for noddy programs.  If you try and do something real in them and your program gets big or your program needs to do low level things you usually end up in more trouble.  Usually the best language to learn is the one which most people speak.

I'm forced to use graphical tools for some of my work and they annoy the hell out of me.  If you are just writing a couple of statements you go ohhhhh that's cool.  But when it gets complicated you get a bunch of spaghetti on your screen and tracing dependencies by following little wires on a graphic is much harder work than writing well structured code in a textual language.  And you end up spending time making pretty pictures rather than focussing on the algorithm.

Becoming reliant on any non-standard proprietary programming language is risky.  The more code you write in it the more committed you are.  What happens ten years out when you have 100 man years of development in that language and they go bust or sell themselves to somebody else who then bumps up the prices or pushes the product in another direction.

I'm in agreement with the rest of the thread. If a visual representation of application flow is that important then there are tools that can generate this from your code flows. Guess what though, they won't be pretty if the backing logic is useful!

If the issue is communication of application functionality to business users I'd recommend looking at cucumber/gherkin with backing automation. Its definitely not easy, but IMO its the closest you can get to understandable explanations of code and process (i.e. living documentation.

If you feel you will get away from having to pay for expensive devs, a visual flowchart tool won't do that, certainly over the medium term!

They are typically serialized to text anyway.

Fully agreed with the rest of your post however.

The only two types of visual programming I have ever encountered that are actually useful are shader graphs and Unreal Engine blueprints. The former because you can generally see a per-pixel preview of every step along the way, which works well for developing something that is by definition visual, and the latter because it can be used for visually wiring up components you have already developed in C++.

Screw developing actual software with this sort of thing...

Re: version control

That technically handles version control but it does miss the power of a really nice flexi-scrolling side-by-side text editor for comparing versions.  

Flowgraphs come up in a other data pipeline places too; one example is GNU Radio.  The right tool for the job.  If the tool doesn't convert the flowgraph to code in a well supported environment or some equivalent I'm not interested...

Visual programming seems to be the right tool for convincing some people to invest in visual programming.  It's over a decade since I used to get roped in to fixing what should be 50 lines of code but sprawls over page after page of LabVIEW and I still carry a grudge.  Still, at least it wasn't in the form of an Excel spreadsheet using a combination of macros and VBA using DDE to pull the data in...  

VBA and DDE? Pah, you were lucky. I once developed an application using Lotus Symphony (google it) that retrieved data in real time via the built in serial protocol that updated a spreadsheet and graphs in real time.

Back to the OP - it's a universal truth in IT that if something seems too good to be true, it doesn't work. My own, deeply held views, is design a database, properly normalised (again, google it if you must), that captures accurately the data and transactions that you wish to process. Done properly the database structure will last ... well, forever really. Then you can access that data with any number of front end tools, simultaneously, from Access and .Net to browser based or mobile based apps.

Yeah; I was wondering how you might diff diagrams...

You can do it with ghosting the versions.

Im not sure if there is any evidence in its effectiveness 

Back in the early 90s I was co-developing a somewhat relational database in LotusWorks 1.0 for formulations and stock control.  It wasn't actually relational, just allowed looking up from one table in to another.  I don't think you would have approved. At all....  I'm still pulling data in and plotting it live over serial ports to this day.  Now it's got some spiteful web front end using the framework of the week.

In reply to captain paranoia:

With screenshots and flip-booking between them.  It's not great, but it helps.  I stopped offering to look at broken LabVIEW in the end.  That helped a lot more.

I know nothing of this coding magic or the viscosity of gerkins and cucumbers and have no idea what a premature ejaculation of a Gnu has to do with computer thingys, but that phrase alone has convinced me this thing (whatever it is) is very, very bad indeed.

Next big thing or emperors new clothes? youtube.com/watch?v=SGUCcjHTmGY&

Frankly, I find that such efforts are always a solution looking for a problem. They automate the easiest part of programming, the expressing your ideas in a programming language, while doing nothing to simplify the hard part, the actual software engineering.

The very idea of typing a leaky loose specification in and having to say what these guys are saying, "I wonder what the model will come up with" fills me with dread rather than delight.

I am aware of some projects using code generation from UML models...

Oh god... They were really pushing stuff like Rational's suite for this stuff a few years ago and it was a dumpster fire. Genuinely if their software itself is meant to be an example of the output of their suite, then it is entirely useless for anything and everything.

I remember being told by our financial director many years ago in a previous job that we should use Power Builder – he was so enthusiastic after some meeting he had had. Needless to say it was not our choice and completely unsuitable. I would choose a new system from a third party now on the quality of the support and their ability to adapt to meet the specific organisational needs. A few times we have gone to tender, the earth and beyond is promised, but then we have been asked to change major work flows to match the software often in a less satisfactory way. Even now, at the moment, looking at a 250 user system we appear to be facing some of these hurdles and I am pleased to just be on the periphery of the discussions even though I have written a couple of small clinical systems in the past that were both in use for over 10 years

Good luck. If it isn't strictly your job you might be best staying out of it for your sanity  

Any one remember "The Last One"?  (The last program you'll ever buy was the claim)

https://modeling-languages.com/last-one-code-generator-basic-1981/

I am one of the senior developers of the current system and being dragged in to provide technical knowledge on it. I've already discussed offline with my senior colleague and we're both highly sceptical about it's ability to replace significant parts of our functionality.

I do, however, vaguely know one of their consultants (I've worked with him before on a project) and he's very good, so that gives it some hope that they might be onto something for a smaller project, but I don't think it will scale to our complexity.