Charles Simonyi, the former chief architect of Microsoft, is arguably the most successful pure programmer in the world, with a personal fortune that Forbes magazine estimates at $1 billion. Bill Gates calls Simonyi "one of the great programmers of all time". He is now pushing a new way of developing software.
Now, some background : Research shows that bad software is terrible for business and the economy. Software failures cost several billions a year,and fully 25 percent of commercial software projects are abandoned before completion. Of projects that are finished, 75 percent ship late or over budget. software itself doesn't run very well. Everywhere you look, software is over budget, behind schedule, insecure, unreliable, and hard to use. Anytime an organization attempts to introduce a new system, or upgrade an old one, it takes a colossal risk; today, large information-technology projects are technological tar pits that immobilize institutions. Studies regularly report that two-thirds of such projects encounter major delays, significant cost overruns, or both. Governments haves found it nearly impossible to introduce or upgrade large-scale software systems. Businesses have fared no better. The article points out that McDonald's executives dreamed of a Web-based management system they called Innovate that would track the real-time flow of burgers, fries, and chicken nuggets in every one of their restaurants around the world. By the time they gave up and canceled the project, they had to write off $170 million of its estimated $1 billion total cost.
What ails the technology world : Simonyi acknowledges that he is disappointed that we have been unable to use “our incredible computational ability” to address efficiently “our practical computational problems.” “Software is truly the bottleneck in the high-tech horn of plenty,” He recommends a new approach whereby programmers will stop trying to manage their clients' needs. Instead, for every problem programmer’s are asked to tackle – business, scientific or system applications, they will create generic tools that the computer users themselves can modify to guide the software's future evolution.
His approach(christend as intentional programming) : Anything that can be done could be done meta. Intentional programming would add an entirely new layer of abstraction to the practice of writing software. It would enable programmers to express their intentions without sinking in the mire of so-called implementation details that always threatened to swallow them. As he sees it, Intentional programming has three great advantages: The people who design a program are the ones who understand the task that needs to be automated; that design can be manipulated simply and directly, rather than by rewriting arcane computer code; and human programmers do not generate the final software code, thus reducing bugs and other errors.
But the the real problem, as Bjarne Stroustrup captures is that software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but-so often-it's not enough. Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts.
As I see it, Intentional software looks too grand a scheme – experience suggests that grandiose vision and technology implementation seldom go hand-in-hand. Incremental rather than radical innovations dot the advancements of programming space. Whilst getting the requirements right is blinding obvious is it not more that such specification has to be in terms and language that are common to the business and the "developer"? To achieve this will require the development environment to change and this in turn will require a completely new design philosophy to building business applications. At the core is the need to recognise how business actually works . His idea presupposes that the business and technical world have a good degree of hold on the art of abstraction. The reality is that we are far from that. This also assumes that business people want to generate software on their own.
Project failure rates attributed to poor capture of requirements is seen as a rising curve and today is the single most often cited reason for project failures. The crux of the issue is not inability to develop clean, neat and efficient program –with tools and experience these objectives can be met – instead the challenge is always getting to give a solid shape to fuzzy and evolving requirements. Business configuring applications on the fly dispensing programmers look too far fetched to me to visualize in real world. I see that even in Business Rules/Process management initiatives where business gets empowered, the reluctance of business to take charge of scheduling or enforcing rules on their own and instead they prefer to work through IT specialists. In the lifecycle of applications, several changes and modifications keep happening and these demand significant attention. Various levels of promise of auto code generators that failed to deliver are still haunting the IT World.The key challenge is that many assume that in real life business world there would be homogeneity in application landscape – that never happens . The rise of EAI,Messaging, chron jobs, CICS –SAP interface, rules engines , BPM tools all point to this. So it could well be time to focus on solving the right problem.
|
