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.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Reader Comments
Subscribe: RSS
View by: Time | Thread
Q&D
[ link to this | view in chronology ]
KISS
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.
[ link to this | view in chronology ]
No Subject Given
In any case, I suspect this discussion strays a bit far into "apples and oranges" territory.
[ link to this | view in chronology ]
Trial and error + reuse
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.
[ link to this | view in chronology ]