Yes, it demos well. But is it maintainable?
A few years ago we created a couple of products to assist customers in converting their Clarify Classic (thick) client forms and code into our thin-client application. Specifically, fcFormsConverter converted Clarify forms into HTML web pages, and fcCodeConverter converted Clarify’s proprietary ClearBasic code into JavaScript or VB6.
These two products demo-ed really well. In a matter of seconds, these applications created decent looking web pages, and the generated code was definitely JavaScript. Wow! Cool!
Not so fast there cowboy. Let’s take a closer look at the generated code.
The HTML code generated by fcFormsConverter:
- All elements are absolutely positioned
- Every element has its own style attribute
- It lacked any security (privilege class) checking
- etc…
The JavaScript code generated by fcCodeConverter:
- Doesn’t effectively deal with Contextual Objects (what Clarify called their in-memory form variable storage)
- It had no way of distinguishing server-side code from client-side code
- Flow structures are different (there are no GoTos in JavaScript, but CB code tends to be littered with them)
- Variable names that leave much to be desired (var t_FC_queryBulk1;)
- etc…
To be fair, fcCodeConverter did a good job translating self-contained APIs that didn’t have any user interaction or UI components. But that’s not where the bulk of the work needs to get done.
In addition, the JavaScript code generated by fcCodeConverter was completely disconnected from the HTML code generated by fcFormsConverter.
In short, the generated code is not maintainable.
Ayende has a recent post titled How to sell maintainability. In it, he states:
Today’s Drag and Drop’s UIs, Wizards and Designers are all mainly focused on the creation side of the software. They help you with the initial bit, and leave you alone afterward. This is great for a demo, but really not a good proposition for the maintainability of an application.
This mimics what we found with fcFormsConverter and fcCodeConverter. They demo-ed well, but when we actually tried to maintain and extend the generated code, we found it typically took longer than writing it from scratch. And when we wrote it from scratch, the code was much cleaner and more maintainable.
Ultimately, we shelved those products. Yes, they demo-ed well. But they didn’t prove themselves in assisting our customers to transition their legacy forms and code to our environment in a fashion that led to good, maintainable code.
Could we have continued to improve on those products? Yes. But I don’t believe it would have been a wise investment. I believe that the transition process of moving from a thick-client app to a thin-client app is also a great opportunity to re-examine some of your business processes, question what was done, re-assess what is really desired, and make your application as robust and maintainable as possible.
- Is there still value in those customizations you made years ago?
- Do you have customizations that are merely workarounds for the thick-client platform/environment?
- Do those same challenges apply in a web application?
- Do the architectural decisions you made for a Windows app still apply in a web app?
In the words of Jeremy Miller: Maintainability is “ility” #1
P.S.
These projects were pretty ambitious, especially the fcCodeConverter. It was basically a compiler, and I have a fair amount of awe and respect for developers that can pull off that type of work. It’s so outside my realm of knowledge (and interest).
