CTO Blog

You are in: CTO Blog

VOTE FOR ME
CIO Blogs
IT Blog Awards

Subscribe

Recent Posts

Navigate


Search the blog

« Does the desktop matter anymore? | Main | Unlikely Love »

Rocket Science

Is there always something new to wish for? In some cases, you are inclined to think not. Take for example Charles Simonyi, an above average gifted programmer from Hungary who joined a modest start-up company in the beginning of the eighties that would later headquarter in Redmond. But not before working at Xerox Parc with IT legends legends such as Alan Kay and Robert Metcalfe on some, well, interesting projects (the first WYSIWIG text editor in the world, somebody had to come up with it). If you joined Microsoft before the PC existed and you sort of single-handedly created both Word and Excel, you may claim some street credibility in the IT profession.

Financially, you are probably doing quite well too: Simonyi is an active philanthropist, with an emphasis on supporting art and culture.

Clearly he saved a little for himself too, as he made headlines in the past two weeks as the tourist who paid 18 million Euros to fly with a Soyuz to the International Space Station. The crew had plenty of work to do there, so no doubt Simonyi had oceans of free time during his stay. There must have been some contemplative moments, Charles having a look through the porthole at Mother Earth, circling underneath.

Reached the absolute top in the profession. In addition, made a virtually impossible boys dream come true. And he might still be asking himself if there is a new daring challenge somewhere, waiting to be cracked.

Fortunately, it looks like Simonyi already has all the clues on where to search. In 2002, he left Microsoft to pursue with his own company the answer to the question that has been haunting the IT industry ever since the very first beginning:

why is it so terribly difficult to develop good software?

Rapid successions of programming languages, visual development environments, case tools, formal specifications, object-orientation, frameworks, agile methodologies, model-driven architecture: whatever we come up with, it seems that the gap between dream and reality - between intention and solution – always stays the same. I just celebrated my tenth anniversary as a jury member of a prominent programmers contest in the Benelux (the ‘RAD race’) and I couldn’t escape the feeling that the productivity of the teams more or less stayed the same during the course of the years. Of course, systems are more complex than ever and we expect better user interfaces and superior services. But it seems as hard as ever – at best – to meet the expectations. It is still painfully difficult to describe business requirements and translate them into working solutions that truly mirror the initial ideas.

Charles Simonyi thinks he has found the answer in an approach that he has coined Intentional Software: provide all the support that is needed to capture the real intention of a solution. Use language concepts – visual, textual – that were meant for that from the ground up. Jargon from the pension world or logistics, actuarial formulas, tables, sketches, drawings: whatever makes a domain expert feel comfortable is suitable. Record the intention in a format that is perfectly independent from its rendering (Simonyi fancies meta concepts) and gape in admiration at all the different representations that allow you to view and edit the intention, all depending on the audience you are targeting for communication.

One of the representations – almost a detail – is code: comes in particularly handy when executing on a computer.

And it truly exists too. We are currently piloting an early version of Simonyi's language workbench and we find that both hardcore software engineers and business domain experts are equally enthusiastic about the approach. Which is not exactly a déjà vu.

You might call it the holy grail of the IT profession: communicating with end users and domain experts in their own language and seamlessly generating systems from that. Without any distortion in between. We have hoped for it before, for example when COBOL and 4GL’s arrived (“from now on, managers can code themselves”). Sometimes, we are very far away: UML 2 is even too complex for its own creators.

But nothing stops us from dreaming.

In practice, becoming an astronaut does not even involve rocket science. Who knows, one of these days we might even find the grail.

TrackBacks

TrackBack URL for this entry: http://www.capgemini.com/cgi-bin/blog/mt-tb.cgi/130

Comments

Good article. I think sometimes the originators of code have been on a different planet. Maybe that's why the evolution to bring business common sense to building applications closer to reality has not happened, as they never quite came back to earth!
This is what drove our founder over 20 years ago. Today maybe we do have that "holy grail" but the cynicism, which you touch on, is a big barrier – as are the vested interests in the continuing complexity.
Lets go back to basics – how does business really work? – People and their daily work/tasks – This is the source of all information – systems only use information as directed by people. From this is it possible to identify the task types both human and system driven? – Answer yes it is. Can these be expressed as “data”? Yes they can. So build effectively business task objects that can be used in any business function that are highly configurable to suit the required circumstances – put a “process engine” into this data centric environment, build a presentation layer and a graphical front end to allow business analysts to build and you have the start of the “new way”. What this has done almost by default is separate business logic which never changes from technology driven communications and opens up a whole new world for digitising companies processes putting people, roles, tasks and data as the core drivers.
The end game? – Heard of Appliance Software being talked about in US? The vision of applications being pre installed in hardware and all hooked up ready for the business. Make it a “generic” capability where the "function" code never changes and the business professional just configures to suit the business requirements. A bit like what a Business Operating System “BOS” should be. Maybe add another S for “Stupid” as in the KISS principle and the BOSS drives the business.


Post a comment

Commenting Policy

Name:
Email Address:
URL:
Remember personal info?
Comments: (you can't use HTML tags for style)