Slashdot Mirror
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."
Keep it simple
Keep it small
You're not gonna be the next Microsoft
Do many releases
Comply with relevant standards
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
There was a widespread belief among physicists that there's nothing more to discover in physics. They were wrong. This guy is also wrong.
When developing a web browser, if a plug-in needs to be launched, don't let the plug-in's loading cause all other instances of the browser to lock up.
I'm looking at you, Firefox.
What's the deal with the PDF-format anyway? The document is 17 pages of Powerpoint-like slides. I'm sure some nice, simple HTML could have displayed that much more quickly. And not locked up Firefox for a minute.
The first law of new software is you do NOT talk about new software.
The second law of new software is...
C'mon, somebody had to say it.
Link to article
Be careful, it locks up Firefox until it loads.
Actual pdf
But seriously, I thought the dot com bust was actually a *good* thing for real programmers. It weeded out all those retards with a geology degree who were in it just for the cash. Granted, those who were actually good at coding made a lot more back in those days. But if you're actually talented then there is no reason you can't make what you want to make. Doesn't matter what the profession is.
.pdf download? First off it's /.ed, second... isn't that what the webpage is there for in the first place?
Anyways, what's the deal with the
By and large there is no need to demand your users trust you with full write access to their home directory, their ethernet device, and more. Consider writing your software in the Java Web Start sandbox.
Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ (Java Web Startable)
All the good stuff has already been thought of, but not everyone knows they exist. Try to find really good ideas by looking back at least 10 years for a piece of software that never took off and has been abandoned and remarket it as the next big thing. Remember: Marketing people could sell blood to a turnip.
It seems like some of these people spend more time writing about software than actually writing software...
www.kiwilyrics.com - a wiki for lyrics
The SIX LAWS of the NEW SOFTWARE
GO AHEAD AND PRINT THIS. This manifesto
continued
is toner-friendly: the backgrounds wont print on paper and are only visible on-screen to aid readability. We recommend printing a test page as some older printers do not support this Acrobat feature.
by Dror Eyal
NEXT
Not using Adobe Acrobat? Please go to http://changethis.com/content/reader
The first wave of software is over, it is doubtful that any one company will capture the market like Microsoft or SAP did. Not because the software they write isn't better or has less functionality, they've simply arrived too late. Most home consumers have all the software they will ever need, and most companies out there already have all the basic technologies they need to successfully compete right now.
I can hear their objections all the way down here, and I agree, your software is better designed, faster, has more features, is more user-friendly and can indeed make seven flavours of coffee. We have something similar, it isnt well designed, it doesnt have half of the features that yours has and no, it doesnt run on Service Orientated Architecture. We did however pay a small fortune for the per-seat licences, we have learnt to use it quite comfortably over the last five years and this is the system that our business runs on. This view isnt limited to us -- Northwestern University economist Robert Gordon, in a 2000 article published in the Journal of Economic Perspectives, argued that "the most important GO AHEAD AND PRINT uses of THIS. This manifesto computers were developed more than a decade into the past, not currently."
is toner-friendly: the Its a fairly bleak view to be sure, but one that isnt unique to Mr Gordon. Many business backgrounds wont executives print on paper and are are turning away from purchasing new technologies and looking for new ways to use their only visible on-screen existing technologies effectively. Not because the new software entering the market to aid readability. We recommend printing a test page as some older printers do not support this Acrobat feature.
isnt better, but because the functionality that they need already exists in software that was bought years ago. Budgets for software expenditure are dropping and the accountants are starting to question why the software that was essential last year needs an upgrade this year. What this means to the average software developer is that the window of opportunity for selling into the corporate market and to some the degree the home market is getting smaller than ever before. So does this mean that this is the end for the software industry? Obviously not, we will continue to develop better products, occasionally new technology will get developed and or a new idea will start a trend and software will get developed around it. Software that meets a new need will always be welcome. Who knew that we needed file sharing software before Napster turned the music industry on its ear? Or that social software and bloging tools were essential if your company was to be seen to be on the cutting edge? No, it isnt the end, but for every tool that revolutionizes the industry and strikes a path into a new territory there are several hundred software companies out there trying to build a better CRM or CMS -- the software industry equivalent of the mousetrap. Obviously it would be better if we all developed software that met a new need and created new markets, but just as obviously we cant all develop revolutionary new software. Most of the software being developed right now in studios around the world is trying to find a niche in existing and saturated markets. So how do you build software that stands out and can compete in this new environGO AHEAD AND PRINT ment? You build a tool based on new generation software laws. THIS. This manifesto
is toner-friendly: the backgrounds wont print on paper and are only visible on-screen to aid readability. We recommend printing a test page as some older printers do not support this Acrob
flossie
Write now. Defend liberty
1. Make sure it's impossible to use.
2. Make sure it's buggy.
3. Make sure it's unsecure.
4. Market the hell out of it. (Making sure to state how great and secure it is.)
5. ???
6. Profit!
...Had this been an actual emergency, we would have fled in terror, and you would not have been informed.
Tools | Options | Downloads | Plugins
Untick PDF.
Now whenever you click on a PDF link you are prompted if you want to view it in Adobe PDF viewer.
Works for me!
Happy moony
"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 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.Step 1: Get rope
Step 2: Tie it in a noose
Step 3: Get a chair and stand on it
Step 4: Tie other end of rope to ceiling fan
Step 5: Put noose over head, snugly over neck
Step 6: Kick chair out from under yourself
Step 7: ???
Step 8: Newsletter!
*Poster does not endorce subscriptions to this newsletter.
Your ideas sound intriguing. How can I subscribe to your newsletter?
Beep. Boop. Beep. You have questions. I have answers and your home address.
Your server gave me this error: It just happened right after I submitted a link to your website from Slashdot.org
I don't know what may have caused it, but you certainly will be able to figure it out by looking at your logs.
Regards,
AC
P.S. I am sorry, I hope I did not break it!
One good rule when writing software would be to assume people are profoundly retarded, thus maximising the possible market share of your software by making it really easy to use.
I can't helpGO AHEAD AND PRINT THISfeeling that some kind of backgrounds wont print on paper subliminal message are only visible on-screen to aid readability is embedded in this This manifesto this post.
do the machinists create manifestos about their work? get over it, programming is mildly creative, but whole notion of paradigm-changing products is grossly overinflated. try doing something that has some obvious utility and dont try to ream people for it.
/* todo: add six laws here */
Anybody who uses "leverage" as a verb is not qualified to comment on the state of computer programming.
1) Make it complex 2) Cram in every buzzword, expensive license, and strategic partnership you can. 3) You're gonna be the next Microsoft. 4) Do no releases. Software thats released gives too much away. Your ideas are too lofty to be nailed down like that! 5) Comply with irrelevant standards For example: "SuperZyzergy.com enabling a new way of doing business on the web! Oracle, Solaris, W3C compliant business solutions, enhancing the synergy of your XML framework!" Company had 40 employees, gold plated everything, a gigabit network back when that cost $$$. The lone technical member of the staff was suffering delusions regarding the wonderful possibilities of an XML enabled world, "even your car will run on XML instead of gas!". He'd recently gotten to parse a small XML file after several months of work, at a salary of $200K/year. Of course most of his time was spent synergizing about business strategy and alliances. Where Oracle would come in he didn't know yet, but he'd already spent $1M on a license deal. The company IPO party cost $5M, and his stock was soon worth $100M on paper. The stockholders saw the value of the XML enabled world, even if the customers still couldn't figure out what they where selling, or even how to buy some of it. [CRASH] As much as the crash and recession sucked, it is kind of nice that technical skill matters again. For a while programming was irrelevant as long as you could sling around long strings of buzzwords with some 'synergies' and 'enablings' thrown in.
Why are none of the 6 "laws of computing," "The software must not, through action or through inaction, allow a human to come to harm?" People we gotta get started early if we want these to be in everything.
He says, correctly, that HTML is the standard for documents on the Web.
He says stick to these standards.
His own article is in a crappy PDF - possibly the lamest format possible for web articles.
A case of "do as I say not as I do"
1000s Warcraft Gold while you sleep
This was also said 15 years ago: go for vertical markets, nothing else is left. And it's good advice, unless you're ambitious. It's b*llsh*t to say all companies needs have been met. Look around you. It's called the "software crisis" for a reason. There is something huge waiting, lurking around the corner. Be there for it.
From TFA:
The author is obviously lives in some parallel universe. I wish I could live there too. Not testing your html in *all* browsers is the most ignorant thing one could possibly do.
I'm trying to improve my English. Please correct me on any spelling/grammar errors in this post.
You can save yourself the effort of rewriting it thrice by just changing the storage format, making minor UI changes, and incrementing the release number. Make sure to get marketting to create a new advertising campaign for the new release, including white care-free young couples smiling in front of the splash screen for your application. Do not take the video or photograph footage for your advertisments at any multiple of 45 degrees on any plane with respect to the orientation of the computer screen (which _must_ be a flatpanel with wireless keyboard and mouse).
The point is: there will be no next Microsoft. So, it won't be you. Got it?
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
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.
putfwd.com - 1GB Free file storage with a twist
The point isn't as much the degree. I think college didn't teach me too much that I didn't already knew, for example.
The problems are (A) if you love programming, and (B) if you have the mental skills for it. At all. Yes, I've been through the "bah, programming is easy, everyone could do it if they wanted to" phase myself. Then you start to realize that things that are trivial and obvious to you, just aren't so for 90% of the rest of the people.
For example, I've actually sat and watched someone painfully try every single of "*", "&" and nothing, on every single variable on a C program, until it stopped crashing. He just could never wrap his mind around the concept of a "pointer". Some 10 years later, AFAIK he _still_ can't. Made me realize that maybe it's not that trivial a concept as I assumed.
And that's just one example. People just aren't built to, basically, think like a machine. They're hampered by natural language fuzziness, and by the human-to-human expectation that the other gets the basic idea and can work out the details for himself.
And it only becomes worse when you deal with people who don't even intend to learn. They're in it just because they "deserve" to be paid a ton of money. And they're not gonna "waste" their time on such boring stuff as actually learning an algorithm, or even the basics of the language they're paid to program in.
I've dealt with too many people whose _only_ interest is hanging around bored until the next paycheck, and their _only_ skill is marketting themselves to a clueless PHB. They can't program worth shit, and they don't even intend to learn more.
And why would they? They get paid anyway. And in the unlikely case that the boss gets a clue and fires them, they'll just move on to another company to scam. There's one sucker born every minute, after all. Not hard to find another sucker who'll swallow a faked resume. Beats actually working and learning.
And, yes, there are a _lot_ of clueless ex-burger-flippers who did just that. Moved into programming not even "just for the money", but "for _undeserved_ money."
A polar bear is a cartesian bear after a coordinate transform.
If you want a truly insightful essay, not on what makes a good product, but how to bring a technical product into the mainstream market, I can heartily recommend Crossing the Chasm by Geoffrey Moore. With this kind of thinking, Microsoft wasn't going to be the next Microsoft, way back when. Don't set up and run your company as if you're going to be a major league company, but be ready for it when it happens unexpectedly anyway. As they say: "Luck is where preparation and opportunity meet".
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Anyone who isn't successful at writing software the first two times around failed at the requirements and design phase.
You V3.0 people tend to dive right into writing the code before you have a clear understanding of what's needed and how to properly architect/design it. Then, say with pride "V3 is completely redesigned from the ground up". Translated: "We failed so badly the first time around, that we rewrote the same software again".
Rules of thumb:
1. Don't start anything until you clearly understand your problem statement
2. Don't start anything else until you clearly understand you end user. If the problem statement is "need to get to work quickly" and your end user is a student, don't design a $75k vehicle.
3. Create a clear and _short_ document that describes what you are going to build. Get it reviewed by many people (the more the merrier), especially your end users. Not only does this provide good feedback (e.g., "I can't use a $75k vehicle"), you might get some good, free ideas on how to build something better. At this point, consider ways to build the project smaller and still get something out the door. Yes, this is the MS philosophy of "good enough". Perfectionists have a difficult time with this stage but there is a lot to be said for good enough software. Your end users will get something in a shorter amount of time, you'll learn from your mistakes when they used the first version and you make some $$ in the mean time.
4. If you're building a tool, especially a UI, build a prototype, let your users test it out and expect to be wrong. You'll need a few iterations to get it right. As a developer, you rarely have the same "perfect UI" as normal people (e.g., you'd prefer more technical language, more complex UI, etc).
5. Think strategically, act tactically. Think about the future of what you're building. Can you create subcomponents that might be useful again some day? Build an architecture diagram if you're working on any significant project and have it reviewed. Think about "pluggable" components at this point. Again, think about "good enough" software.
6. Build crisp and well design interfaces (APIs). An interface that gets a lot of use from end users will be very difficult to change in the future. Build something that has at least some level of adaptability. For example, having a "options" argument as the first argument is not a bad idea since you can change the behavior at some point in the future without changing the API. This is the time to thing about "black box testing". Based on your architecture diagram and crisp interfaces, could you pull out a component and have it tested simply by driving its interfaces? Have the interfaces reviewed.
7. Once you have the components and interfaces designed, consider the design of each component. This is also a good time to go back to steps #1, #2 and #3 to make sure you're still building the right thing for your users and what they agreed to in step #3. Have the component designs reviewed.
8. Build the interfaces (read: write code). Pay special attention to serviceability of these interfaces. I.e., you might want to trace what is passed across these interfaces).
9. Build the components (read: write code). Again, pay special attention to serviceability. If something fails in these components, could you diagnose it remotely with your problem determination facilities?
10. Unit test. Test error paths and other "rare" code paths that would otherwise not be tested by driving the external interfaces. Test your serviceability features to make sure they work.
11. Test the externals by driving the components via their interfaces. If you have an automated test tool of some kind, get your tests hooked in. This might sound like a lot of work, but it is so good to know that if someone else's change "breaks the code" it is their fault and not your responsibility. If you don't have your code tested as part of the official methods, you'll be fixing problems that other people c