* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!


» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)


Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Major redesign/business decision - seeking perspectives

Not sure if this should go in Design of Software or here.

I have a Windows C++ based app which uses MFC for the GUI (lots of dialogs, custom controls, etc).  The UI is _very_ rich, fairly polished, fast, helpful error messages, handles status animations on potentially thousands of items, etc.  The GUI is a competitive advantage over many competitors.

The GUI talks to a service on the same machine (and also some databases, registry, web services, etc).  There is a concept of a data layer, though it isn't perfect.

Imagine a business app where the user inputs data which is processed by the service.  The entered data is fairly complex.

I have business needs to do two things:
1. Make the underlying service be able to communicate with peer services across the Internet.  The service already has a built-in HTTP server, so this will be done via some sort of HTTPS-based RPC calls, which is already somewhat in place.

2. Make the GUI be able to run on a separate machine, and connect to the service over the LAN/Internet for data processing.  This is where I'm stuck.  Should I:

  a. Make the GUI's data layer use the HTTPS-based RPC calls (and there would have to be many of them to handle all the stuff it does now, plus lots of caching to make it perform well).  I can do this piece-meal (slowly move internal data layer calls to the HTTPS-based RPC, and have already done a tiny bit).  Lots of work here. 

  b. Scrap the C++/MFC GUI and make it web based (so you'd connect to http://machine:port to get to the app's GUI).  This would use the embedded HTTP server, maybe with Python support added (using IIS or Apache is not an option from a business perspective).  Lots of work here too.

My guess is (a) could be done in 3-4 months, while (b) might take 6-12 months (I'm not an HTML GUI guru at all). 

(a) is attractive because of time frame and it can be done in phases (while still adding other features to the app)

However, 5 years from now I can imagine I'll wish I had done (b) because it could support clients on Mac, Linux, etc.  Also, sticking with (a) feels like I'm falling behind (I'm starting to feel a little how assembly programmers might have felt like when C was all the rage).

What would you do in this situation?
Friday, August 15, 2008
Im in the same boat with you regarding "web programming".  I say bite the bullet and use this as an opportunity to learn web programming.

That is of course if the schedule fits your needs.

Best of Luck.
Nick Koranda Send private email
Friday, August 15, 2008
"Make the GUI be able to run on a separate machine, and connect to the service over the LAN/Internet for data processing."

Have you investigated whether something like Citrix can't be used to run your application on the server? It really can work very well when used correctly and with the right infrastructure.
Friday, August 15, 2008

Thanks for the idea, but...
Customers are already using Remote Desktop to get to the 'central' machine today and they're complaining about it.  Citrix and other such solutions would just add installation/configuration complexity and cost to my solution.  It really does need to run remotely :(
Friday, August 15, 2008
"The UI is _very_ rich, fairly polished, fast, helpful error messages, handles status animations on potentially thousands of items, etc.  The GUI is a competitive advantage over many competitors."

I thing that redoing this with a web-based could be a problem since you are fairly new to web programming.  You would lose that competitive edge and then be behind others instead.  I know a large medical department of a company that had everything as a web-based app and to do the new things that they wanted it was easier for them to redo it as a Windows Forms application instead.  Yes they had alot of manpower to do it, but the issue is that they went the other way to get a richer easier to program experience.

I am not saying that it cannot be done.  There are some fantastic web-based applications out there.  And some fantastic web programmers that support them.  My personal preference would to not go web-based.  YMMV
SteveM Send private email
Friday, August 15, 2008

In scenario 2,

Why not do (a) with (b) in mind?

It seems logical since the GUI is a competitive advantage today.
Tov Are Jacobsen Send private email
Friday, August 15, 2008
From a risk management and business POV I'd go for the RPC interface.

Developing a polished web-interface is a major undertaking. The differences between browsers, the many applicable standards etc mean that you'll have to absorb a lot of information before you'll be developing top-quality webapplications.

There are several risks with the webinterface approach. Since you're new to webdevelopment you can't really trust your own estimate on the time it will take to develop that interface. A partially developed webinterface won't do you any good so you'll be investing a lot of time / effort with zero payoff until the end. From a customer point of view, you're not even generating any value most of that time since you'll just be duplicating existing functionality. There is a lot of risk and little gain it seems.

So if I were you I'd go with the RPC route, or some other client-server solution. I'd start developing webskills on a separate track, for instance starting with a web-based graphical reporting application. Maybe you can provide management information based on your application to current non-users within your customers organizations. Since you're developing new functionality you can release early. This limits your investment and gets you into a tight feedback cycle with your customers.

Then again I'm a webguy myself so I might be completely underestimating the challenges with the RPC route ;)

good luck,

Mathieu Send private email
Friday, August 15, 2008
I'd keep your GUI and move everything behind a web service layer.  If the GUI is your competitive advantage, it's a big risk to rewrite it in a technology that less capable and that you are not as knowledgeable in. 

I'm sure that there are lots of little details that you have gotten right that will drive you crazy when you can't have them on the web -- and they will drive your users crazy as well, if you compromise.

You can always add on a web interface later, and if you still have the GUI, it can be less capable because it's an alternative to use if you don't have the client installed (like on a mobile device or home computer).

You could also look into Silverlight or Flash which both support web services, can run in a browser, and have advanced GUI controls.
Lou Send private email
Friday, August 15, 2008
++100 for good web development is really, really tough, especially if you've never done web stuff before.
Steve Send private email
Friday, August 15, 2008
I have a desktop GUI, whose network API to the server looks like a Web request. I may implement a Web UI later.

When you're rock-climbing you're supposed to have three 'points' on the rock at all times: move a hand, *or* move a foot, but never have two limbs that aren't holding the rock.

Similarly when you're coding: instad of changing the UI *and* the network protocol, you might like to do it in two stages ...

* Keep the current UI, and code a new network API for it
* Keep the current network API, and code a new UI for it
Christopher Wells Send private email
Friday, August 15, 2008
Choice (c) would be to use a cross-platform tool for creating a rich GUI that talks over HTTP to the other services. There's no reason to limit an internet application with an HTML-based GUI.

There are a few cross-platform toolkits worth considering. For example, Tcl/Tk runs just about everywhere and has a trivial deployment mechanism. You can deploy everything you need as either a single platform specific file, or split up into a platform independent file and a platform specific runtime, all neatly organized in a single virtual filesystem.

And lest ye say "wow, Tk looks like it came out of the '80's!", be aware that the latest versions have native widgets on the Mac and Windows (there's really no such concept of native widgets on linux).

Tk isn't as rich as MFC or Cocoa, but does have all the basics, and most everything you need can be found either built-in or available as an extension.
Just another voice in the crowd
Friday, August 15, 2008
> What would you do in this situation?

There isn't a lot of detail here.  A lot of this will be driven by platform requrements.

If you need to go client/server on Windows, and your data is relational at all, then why can't you move to something like SQL Server?

The migration path would be to improve the data layer until you've go it completely abstracted, and then develop a local version and a client/server version so that you can do side by side testing.  If you refactor the code, then it should be possible to break it up into rich and thin client versions.

It's certainly doable.  I was part of a team that created a MFC client/server app (millions of lines of code, ActiveX based) which has been migrated to Java, then ASP.NET C#, and now back going back to Java.  A lot of it comes down to your ability to logically partition the app into classes/controls/etc. that are agnostic of the transport.  That way you can use C++ to C++, SOAP, ADO, whatever, and the GUI never knows which data provider it is talking to.  The product I worked on years ago has made it through so many migrations successfully because it had a pretty good OO design to begin with.
David C. Blake (Ardfry Imaging, LLC) Send private email
Friday, August 15, 2008
"using IIS or Apache is not an option from a business perspective"

You can create a .NET Class Library project/assembly which will connect to the server using .NET Remoting.
Expose that assembly as a COM object so that you can call it from your MFC code.

No need for a Web server.

.NET Remoting is very powerful.

Windows Communication Foundation is even better.
Just as an example, you can use Duplex channels which will call clients who are behind NATs and firewalls (that is, the server calling clients, - as opposed to traditional client->server request-response model).
The only disadvantage compared to .NET Remoting is that WCF requires .NET 3.* runtime, and some "slow" customers might be still hesitant to upgrade from 1.* to 2.0 ;-)

One of those two might be a good option instead of a Web service.

Web services are ridiculously easy to build, but installation/configuration is a royal pain in the a$$ if you have to make them really secure and to do that automatically at installation time.
Dmitriy Send private email
Friday, August 15, 2008
What kind of infrastructure will be separating the client and the server? Internet, VPNs, private WANs (e.g. MPLS)? What kind of bandwidth will customers have - a lot of people still rely on ADSL and that asymmetry can be a killer for some apps.

I'd recommend setting a small test LAN with a WAN emulator (there are decent free ones) for testing your solution - particularly if you go down the RPC route. This allows you to specify different line properties and then check what will happen to your application.

Out of interest, do you have specific problems with things like Citrix (OK apart from cost) - when set up properly it can be really effective!
Friday, August 15, 2008
Doing a good Web UI is orders of maginitude more difficult than a rich client. If your GUI is currently a competitive advantage, stick with it. See how far you get doing course grained operations,prefetching and extensive caching.
Sunday, August 17, 2008
Two words: Java applet.
.02 Send private email
Sunday, August 17, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz