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.
Comments on “Big Flexible Software Or Focused Situational Software?”
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
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.
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.
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.