Big Flexible Software Or Focused Situational Software?

from the the-next-big-software-battle dept

Earlier this year, we wrote about Clay Shirky’s vision of situational software — suggesting that a new (often, younger) generation of software developers wasn’t focused on big, web-based applications that could scale, but small, quick-and-dirty applications to serve a specific purpose for a specific group of people. In fact, they were often designed by non-programmers, with the goal of just making one particular task for one, focused, group more efficient. This view of things has been supported by people like Charles Simonyi who is trying to work on tools to help people build such quick-and-dirty apps without any programming background. At the same time, efforts from Sun and Microsoft to offer up increasingly simple tools for non-programmers to program all suggest a move in that direction. However, from Between the Lines, comes a pointer to an analysis that appears to be suggesting exactly the opposite. As the world moves towards service oriented architectures, it predicts “the end of craft software”, which will be replaced by big, but flexible, web services components that can easily be modified to meet ever-changing needs. The suggestion is that, by designing to web services standards, developers will finally be able to wipe out some of the quality problems associated with existing software offerings. Both sides seem a little idealistic in their visions. For years we’ve had attempts at making programming tools for non-programmers and that hasn’t gone very far. Meanwhile, the idea of componentized jigsaw puzzle software has been trotted out on a fairly regular basis — and while there have been religious wars on various implementations, very little has actually changed in the way most companies develop software. So, which direction is the world really going in? In some sense, the answer may be both (and neither). The idea of more open “service oriented” systems is clearly the way where enterprise systems need to move. However, beneath that level, the idea of more niche, focused applications (perhaps designed by non-programmers) for specific needs still has a very large (and rapidly growing) place.

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “Big Flexible Software Or Focused Situational Software?”

Subscribe: RSS Leave a comment
anonymoose cow-ard says:


Many of the early UNIX command line tools had the KISS (keep it simple stupid) concept. Create a small tool that does one task and does it well. Allow the output of one tool to be used as the input to another tool (thus chaining them together for a more powerful tool). grep, sed, awk and other UNIX tools all follow this philosophy.

There are FAR too many huge monolithic applications that try to solve every task imaginable (any usually don’t do any of them very well).

Bring back the days of small, simple, quick tools that do one job and do it well, and let ME decide which tools I want to use to accomplish a task.

blairkincaide says:

Re: Trial and error + reuse

Giving the non-programmer tools to create solutions is a very good thing because they are often the ones who understand what solution it is they need. That being said, there are potential dangers involved since multiple applications often relate to each other and will have to compensate for error. This will probably create a tollerance within applications for bad coding practices which will negatively impact standards.

I’ve experienced a growing trend of a new “hacking” mindset in web development where, rather than truly understand or interpret a programming language, individuals find snippets of code and cut/paste these snippets into their applications in a sort of trial and error scenario. The problem comes into play when those lines of code contain extra “dead” information that is left over from the previous application. If the programmer had truly understood the code, they might have been able to write a line of code from scratch that was either simpler and more effective. Or they would have understood how to safely reuse a piece of code avoiding potential future problems.

Add Your Comment

Your email address will not be published. Required fields are marked *

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...