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.

Reader Comments

Subscribe: RSS

View by: Time | Thread


  • identicon
    xper, 3 Sep 2004 @ 7:49am

    Q&D

    Quick & dirty apps is how we got stuck with UUCP for all those years! (Michael Lesk knocked it up quickly to get some files across the machine room one day....) Q&D apps simply don't get thrown away, they get adapted and become monsters. Bad idea

    reply to this | link to this | view in chronology ]

  • identicon
    anonymoose cow-ard, 3 Sep 2004 @ 8:29am

    KISS

    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.

    reply to this | link to this | view in chronology ]

  • identicon
    Brian Shock, 3 Sep 2004 @ 8:54am

    No Subject Given

    Small, purposeful applications can be very useful, but any app created by a true "nonprogrammer" (i.e. someone incapable of codifying processes or following instructions) is going to suffer from serious flaws.

    In any case, I suspect this discussion strays a bit far into "apples and oranges" territory.

    reply to this | link to this | view in chronology ]

    • identicon
      blairkincaide, 3 Sep 2004 @ 10:35am

      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.

      reply to this | link to this | view in chronology ]


Add Your Comment

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



Subscribe to the Techdirt Daily newsletter




Comment Options:

  • Use markdown. Use plain text.
  • Remember name/email/url (set a cookie)

Close

Add A Reply

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



Subscribe to the Techdirt Daily newsletter




Comment Options:

  • Use markdown. Use plain text.
  • Remember name/email/url (set a cookie)

Follow Techdirt
Insider Shop - Show Your Support!

Advertisement
Report this ad  |  Hide Techdirt ads
Essential Reading
Techdirt Deals
Report this ad  |  Hide Techdirt ads
Techdirt Insider Chat
Advertisement
Report this ad  |  Hide Techdirt ads
Recent Stories
Advertisement
Report this ad  |  Hide Techdirt ads

Close

Email This

This feature is only available to registered users. Register or sign in to use it.