Making Software Design As Simple As Creating A PowerPoint Presentation
from the good-or-bad? dept
A few months ago we wrote about Charles Simonyi’s efforts to build tools that would make creating applications as easy as making a PowerPoint presentation. While we wondered whether or not that was really possible, others were more afraid of the inevitable “idiot-ification” of programs if that happened. People like Edward Tufte insist that the dumbing down of our thinking by PowerPoint has dangerous consequences – so just imagine how he (and others) will react to the dumbing down of programming. Already, people revolt against ideas like Visual Basic. News.com, though, is running an interview with Simonyi where he describes in more detail the ideas behind Intentional Software. It doesn’t sound quite as drastic as the original descriptions (though, still quite revolutionary, if it can be pulled off). They’re not trying to build the tools to make it easier for non-programmers to program themselves. Instead, they’re building a system so that programmers can build an environment for non-programmers to build subject-specific programs, which is actually quite different. As he explains, before, programmers would talk to subject matter experts about what they were trying to do, and then try to build a program that represents that. The goal of Intentional Software is still for the programmers to talk with the subject matter experts – but then to build a system for the subject matter experts to build their program. It still sounds like a very difficult task, and one that I’m sure will still draw plenty of complaints.
Comments on “Making Software Design As Simple As Creating A PowerPoint Presentation”
Are we solving the right problems?
I’m all for tools to make programming easier when it makes sense; that’s why you have PERL and VB instead of using C++ and Java for everything.
The concern I have isn’t that we have easy enough tools for programming – it’s that we don’t have simple, intuitive ones for process/workflow modeling, which would help people avoid using programming tools to automate bad designs & processes.
I’ve seen too many situations where simple programming tools facilitate either or both of these bad-automation drivers:
– “Power Users” who understand a business problem, but don’t know enough about programming to properly automate a solution, or even assess if tools like VB or Access are appropriate platforms for what’s needed.
– “SWAT Developers”, who know the tools well, and measure their success by how fast they can use them to implement a RAD-style solution on behalf of a client. These folks often have the same platform-assessment blindspot (i.e. just because you CAN build it in a given tool doesn’t mean you should).
If you had good, easy-to-use tools to help model the problem/process itself, we’d have a lot better upfront analysis and successful solutions following them.
(Yes, there are some tools like this, but they’re either too complex, or only suited to modeling processes that can be automated in Excel/MS-Office)
Re: Brilliant
This idea sounds brilliant. Too often stakeholders aren’t involved in the process enough… when project managing, I spend a lot of time talking with them about what things do and don’t work, what can be done and can’t (efficiently, nearly anything can be done but the effort involved isn’t cost-effective.) To have them walk through step by step and “design” the application would be immensely useful. And I agree about modifying the code into machine generated bits, too. Again, cost-effectiveness isn’t always a consideration to the programming side. I’ve seen them argue and fuss and spent time optimizing something for a 10% improvement, or a tiny improvement that almost no one but they would see…