Situational Software: Who Says Software Needs To Scale?
from the an-aha-moment dept
It may be time to adjust your thinking on software design. Admittedly, we have been skeptical of Charles Simonyi’s Intentional Software plans, which even he described as making it as easy to create an application as it is to create a PowerPoint presentation. As his plans have become clearer, though, the idea has been growing on me – though, I still think it will be difficult to pull off. However, I’m beginning to think that I’ve been looking at it completely backwards. Clay Shirky has just written a fascinating article on “situated software”, talking about how kids today, when asked to write a program, are approaching it in an entirely different way than those who learned to program for the web. Instead of focusing on issues like “scalability” and features that make it easy for a generic user, they designed specific apps for their social groups who they knew would be using it. They didn’t worry about the big issues that would come up if the application would be expanded to a larger audience. In fact, it appears that many figured out a way to use the smallness of the userbase to the application’s advantage. Reading this, I realized that this is exactly the way we’ve been working on certain applications within our tiny “Techdirt Labs” operation. These are applications that are only for internal use, where things like scalability and generic uses take something of a backseat to features that fit with what we need (improving the ability of our analysts to do their work). As such, something like Intentional Software (if it works) suddenly seems a lot more appealing. Everyone involved in these projects has ideas, and if they can all easily make adjustments and create the software that works for them or their small group, it would be much easier. Shirky’s article makes one other interesting point along these lines. He talks about how MySQL makes it insanely easy to create an application on top of a database, and points out another reason why outsourcing fears are overblown. While firms like Gartner are predicting that there will be “fewer programmers” in the US due to outsourcing, Shirky goes the opposite direction, suggesting that this lowering the barriers will make more people programmers – just not in the traditional sense. He compares it to someone in the 80s saying that there would be fewer typists in the 90s. Technically, it’s true, but it’s missing the bigger picture. The same could be said for switchboard operators years ago. Nowadays, we’re all switchboard operators. As with switchboard operators and typists – the new tools, and what they allowed opened up tremendous new possibilities. It looks like software development may be next.
Comments on “Situational Software: Who Says Software Needs To Scale?”
No Subject Given
Mike, I think this kind of thing is going to hit the market all over the place.
But if the goal of these applications is to create more pseudo programmers, by allowing business people to do their own thinking, then none of these products will are going to sell very well.
The goal behind qbasic and visual basic was to make applications simple enough for business people to do just this sort of thing. And it did, in many respects. But the bottom line, and the reason that there are qbasic and Visual Basic “programmers” today is because non technical people don’t want to do their own programming. Doesn’t matter how simple it is.
If on the other hand you take these same tools, and sell them as a way to make programmer’s lives easier, people will generally listen.
Re: No Subject Given
Sammy, I think that’s the opposite point. T
These guys do not create any software as a way of living. You cannot see this with a business view. You gotta see this like a trend that will occur in the future. no matter what, you will have people around who could make any program up in a matter of hours.
project lifetime
This approach makes sense when the expected lifetime of the project is measured in months, which is likely to be the case for student projects or for a proof of concept. For software that lasts much longer than a few months, taking this approach usually requires a lot more work over the long run because people have to keep redesigning it to handle new requirements, or more often it ends up being completely rewritten at least once. The trick is finding the right balance.
Its nothing new.
When I was in college I wrote a program that catalogued cds/tapes/mds and help track listings etc and ratings/comments. Other students in my year group liked it and downloaded it from my site, eventually it had over 80 downloads.
The actual application was written in pascal 7 was very well written (even if I do say so myself) but was written in such a way that it would have been horrible to add new features or reuse bits like filehandling routines or sorting algo’s etc. I got a high grade for the work nevertheless and carried on to uni. Whilst there I learned about OOP and C++/Java, JSD/JSP and all sorts of brainwashing/useful? ‘standards’.
The skills I learned in uni were the industry standards that would enable me to get a job, but along with those skills comes a bunch of mind programming by the subjects you are taught to think about software development in a certain way.
It steers you away from bespoke hacking of spaghetti code to ‘just get an idea done and worry about the code readability/layout later’, you actively dont want to do that anymore. So in effect it stifles your productivity because its either too much hassle to begin or too much hassle to finish unless you do it right. Doing it right though is not always the quick way when keeping to good practices.
At this point though is what defines a good from a lazy(read crushed) programmer. The good ones retain the ability (that we all had when starting to program or we wouldnt have kept at it) to still keep their original outlook on development as ‘fun’ and plug away at it with their ideas to completion. Then theres the lazy programmers that just see it as a job or a means to an end(paycheck).
Thats just an opinion and may be jaded by the amount of contractors and novice programmers I have worked with, but in my eyes its a very real analysis of what happens.
Chris
The other part is the
Clay is really talking about two things:
We’ve been thinking along the same lines, see my Situational Software Blog that just went on-line and that is exclusively focused on that subject.