Six Laws of the New Software

LordFoom writes "Still suffering from post-dotcom stress disorder, I keep my eye out for gentle balm to sooth my ravaged psyche. The manifestos at ChangeThis are not it. The most popular manifestos range from irritating to enlightening, with none of them particularly comforting. In particular the recent Six Laws of the New Software have done my dreams of writing lucrative code no good - although it has changed my idea of what money-making code is."

Re:Hope I'm not trolling too hard...

[winkydink]

Actually, it didn't. A lot of those retards hung on to their jobs while good people got canned.

The biggest thing that changed and has not changed back is that before the boom, people went into IT because they liked it, the money was secondary. Now, there are many people in IT for the money and to them it's just a job, not a passion.

The "Collaborate" Suggestion and Unix

[Zergwyn]

Most of these suggestions are common sense to anyone who has a couple of serious software projects under their belt, which isn't to say that they aren't worthwhile to look through. However, one in particular made me think of an old question of mine, having to do with the way unix works vs the modern GUI. On page 6, the pdf discusses the "Collaborate Law". It says:

"Forget enterprise systems that do everything possible within your field. They're too large, clumsy and require too much development time. Instead, create small discrete software that can collaborate seamlessly with the technology that the end users are currently using."

This, in a nutshell, seems to be the core philosophy behind much of the original Unix. Most Unix apps (and in particular, all the 'commands' which are small applications) have the concept of standard in (stdin), standard out (stdout), and standard error (stderr). Because most commands can operate to accept stdin, do its purpose, and then send to stdout, it is both possible, intuitive, and very practical to chain together many small commands to accomplish a single task very easily. I suspect there is some terminology for this process, but as I don't know what it is I generally think of it as being a "stream centered" approach. You have many discrete components operating on a stream of information. However, I know of no similar functionality in most modern GUIs, which are all basically application-centered approaches (though Windows tends to present itself as being document-centered). Each application is a single thing that you open up, and has its own self contained operations, usage, etc. I would like to see this more object-oriented stream approach exist in more GUIs today, because it is really a very useful paradigm for many tasks. It allows developers to concentrate on doing a single task extremely well, and then allows users to chain that task in as many ways as they can imagine, which is always more then what the original developer could think of. In Mac OS X 10.4, the Automator [apple.com] feature sounds like it might very well be close to what I have in mind, though a lot will depend on how easily and powerfully developers can make new 'Actions' (Apple's terminology for single task apps/commands). However, these days I really think that is an old concept that is time tested and very useful and just waiting for the right re-implementation to become critical for a new generation.

Re:Here's another law to add

[Anonymous Coward]

No, that page skirts the issue.

The issue that the parent noted was that ALL Firefox instances freeze up when Acrobat is loading.

One instance freezing is acceptable (not really, but whatcha gonna do?), but all instances freezing is a bug in Firefox.

Re:The "Collaborate" Suggestion and Unix

[mattkime]

if you go back in time a bit, there was Apple's OpenDoc. I've forgotten why it failed, but i think it had something to do with the fact that people want to buy apps, not app parts. Also, AppleScript has always been able to tie apps together, even back in the OS 8 days. (Which automated ad placement for many newspapers, drawing info from databases.) ....but people rarely use them because they're lazy.

Re:The "Collaborate" Suggestion and Unix

[Leo McGarry]

Not so much "could become" as "is." Automator is based on the idea of creating ad-hoc workflow pipelines, just like the UNIX command line. Except you're not limited to textual input and output, and the workflows can be saved for later execution.

Think of it as the natural evolution of the pipeline aspects of the command line.

Re:In a nutshell

[Doomdark]

Or maybe there just will never be another Microsoft; as in no company will duplicate the (early) life-span of Microsoft. That's entirely possible -- perhaps time for mega-corporations based on standard expensive shrink-wrapped applications is over?

This is not to say there couldn't be other mega-corps in software, just that they would probably become such using different kinds of products, strategies and so on.

What I don't understand, however, is the last part ("play to win, or give it up now"): are you implying there is no other way to succeed than the Microsoft way? I'd think that's bit short-sighted. Besides, Microsoft didn't exactly get started on great unstoppable visions, but with rather simple ideas of building basic interpreters (etc) to sell for hobbyists. The vision part only came when they grew big, and made founder(s) think they need to have visions; bit like how George Lucas keeps on reinventing the history of Star Wars.

Why does everybody think software is different?

[lux55]

The business models employed in the software industry are no different than in other industries, yet software makers continually try to convince themselves that they are the only area of business where the only way to make it is with entirely new ideas. Perhaps those who make it do so because of things like good timing, and more knowledge about how business actually works (ie. what plans work in what circumstances, how to see the patterns into which said plans would fit, as they're emerging). The second biggest problem in software is people who continually try to publicly pat themselves on the back and call themselves "original thinkers". The biggest problem in software are the people who believe them.

Re:Hope I'm not trolling too hard...

[Ginnungagap42]

I am in violent agreement with what you say. However, in 20 years of programming, the singular worst code I ever saw was written by a guy who had a MS in Computer Science from Virginia Tech who shall remain nameless because I'm a nice guy. Not only was his code at the Bubble Sort level, he got the wrong answers for the problem set! He was much better at marketing his own code than actually getting it to work. He ended up convincing Management that his code was the hottest thing going, and when he quit the company, the rest of us who were eventually brought in to "maintain" his code (and discovered what crap it truly was) were labelled idiots because we "didn't understand his genius."

Of course, the software he wrote took more than 8 hours to run. When our team (dedicated hackers and code monkeys) got through fixing it, we could run it and get the RIGHT answer in about 5 minutes.

Give me a geology major who loves to program any day!