Six Laws of the New Software 313
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."
In a nutshell (Score:5, Informative)
Keep it small
You're not gonna be the next Microsoft
Do many releases
Comply with relevant standards
Direct link (Score:4, Informative)
Be careful, it locks up Firefox until it loads.
Next time I'll check the link better. (Score:5, Informative)
pdftotext (Score:5, Informative)
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
Hint: How to avoid PDF lock-up in Firefox (Score:5, Informative)
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!
Re:Here's another law to add (Score:1, Informative)
And every single time this issue is brought up, someone tries to defend Firefox's broken rendering as a bug in Slashcode. While Slashcode may be broken, this particular problem is in Firefox and can be generated with 100% W3C compliant code (see bug report).
Until just recently, the Firefox team has ignored this issue as an external bug. Even now, they only provide a "fix" which is nothing more than a workaround their broken rendering engine.
Re:The "Collaborate" Suggestion and Unix (Score:1, Informative)
Re:Here's another law to add (Score:4, Informative)
Re:Here's another law to add (Score:1, Informative)
Re:Here's another law to add (Score:1, Informative)
Re:Here's another law to add (Score:2, Informative)
Easier said than done. If you try and hide the plugin, mozilla and firefox often go looking for it. Eventually I had to just delete the shared library on linux. On windows, I had to edit the preferences file to look for a version of acrobat that didn't exist yet.
The plugin is so annoying because its toolbars take up a lot of space along with firefox's.
Re:Here's another law to add (Score:2, Informative)
Yes, disable it, and use a quick and functional third-party PDF viewer like this one. [foxitsoftware.com] Acrobat in an ponderous, bloated abomination, kind of like Mothra in larval form.
Re:In the end of last century... (Score:1, Informative)
If you're going to trot that out you could at least bother to get it right.
I find your ideas intriguing and would like to subscribe to your newsletter.
Re:Here's another law to add (Score:3, Informative)
Re:Here's another law to add (Score:3, Informative)
Re:Here's another law to add (Score:3, Informative)
Boy, that's for sure. And you're not the only one who thinks so; see Jeff Jarvis' [buzzmachine.com] and Doc Searls' [weblogs.com] rants on the subject, which prompted a response [typepad.com] from ChangeThis' founder, Seth Godin:
Maybe he should have just gone all the way and printed them as books, then?
Re:In a nutshell (Score:3, Informative)
They have 3 or 4 areas where their products are dominant (operating system, word processor, spreadsheet, etc..) and those areas are impressive, but what about all the areas where they have commited tremendous amounts of resources just to get minimal market share or fall flat on their face. For every product they have been successful at there are dozens that have less than optimal market penetration (xbox, IIS) or are losing ground (IE). Ten years ago, when there wasn't a competitor in sight, they could have focused on building the best operating system possible. Instead every release was overpriced, unstable and characterized by new shiny buttons. Now OSX, linux and Open Office are serious competition in their primary markets. They will have to regain some focus and dump some of the waste to survive long term.
Gates and company were in the right place at the right time, that's why their products are successful. There have been many companies just as ruthless that are now just memories.
Re:Here's another law to add (Score:5, Informative)
Back in the olden days, there was this thing called QuickDraw. QuickDraw was pretty incredible. It consisted of a full-featured set of routines for drawing on the screen, and the whole business fit inside something like 32 KB of ROM.
QuickDraw was based on the idea of pixels. Everything was a pixel. Drawing with QuickDraw was based entirely around pixels.
Quartz abandoned the idea of pixels in order to give programmers a device- and resolution-independent graphics toolbox. Quartz consists of two parts: a drawing library called Quartz 2D, and a windowing and real-time compositing system originally called Quartz Compositor. A couple years back, Quartz Compositor was re-implemented in GPU code and re-christened Quartz Extreme. (Quartz Compositor still runs on Macs without programmable GPUs.)
The imaging model used for Quartz 2D was inspired by both Display PostScript and PDF, but it's not the same as either of them. Unlike QuickDraw, where everything was about pixels, in Quartz 2D it's all about paint. Quartz 2D establishes a floating-point coordinate system called a context, and the programmer draws on the context by defining regions and filling them with paint. Internally, everything is represented as a display list, as opposed to a bitmap like in the old days. The display list gets rendered to the screen by Quartz Extreme.
Because Quartz 2D uses a similar imaging model to PDF's, Quartz 2D display lists can be translated to PDF trivially. The whole business is handled for you. All you have to do is request a Core Graphics PDF context instead of a regular Core Graphics context and draw to it just like you were drawing to a window. Core Graphics is responsible for translating your Quartz 2D display list into PDF.
So let's be totally clear here: None of the graphics on your Mac are represented internally in PDF format until your program explicitly requests that a display list be saved in PDF format. Internally, everything is a Quartz 2D display list. The computer converts to and from Quartz 2D quickly and easily through the use of some highly optimized Core Graphics code.
Now, you wanna know why Acrobat is so much slower than Preview? Because Acrobat uses its own PDF interpreter to go from PDF to QuickDraw. This takes a ton of CPU time, compared to going from PDF to a Quartz 2D display list. So Acrobat is both much bigger (because it includes a whole PDF interpreter) and much slower than Preview.
On Windows or Linux or whatever other incredibly lame operating system you want to consider, a PDF reader is necessarily going to be big and slow, because it's gonna have to translate from PDF into some bitmap format. Old operating systems don't have the advantage of having an internal display-list graphics format that's conceptually similar to PDF, or a hardware-accelerated compositor that's responsible for turning those display lists into pixels. But that still doesn't change the fact that the PDF specification is wide open, and anybody who wants to should be able to write his or her own PDF reader for those old operating systems.
Incidentally, Quartz 2D used to be notably slower than QuickDraw for doing lots of basic tasks. If you take antialiasing and transparency off the table and just deal with drawing lines, QuickDraw used to kick Quartz 2D's ass. No more, though, because Quartz 2D has recently been rewritten to take advantage of programmable GPUs, just like Quartz Compositor was rewritten and became Quartz Extreme. Now, depending on the kind of GPU you have, Quartz 2D can be anywhere up to 40 times faster than QuickDraw
Frankly, it kinda makes me wonder why more people aren't raving about Quartz. I guess it's probably because most people don't unde
Re:Here's another law to add (Score:2, Informative)
Just now I searched for a free PDF viewer. I found Foxit PDF reader [foxitsoftware.com], which is a free lightweight PDF reader.
It opened the same document very fast.
"Somebody has to be"... (Score:2, Informative)
Good points but lacking insight, wrong conclusion (Score:3, Informative)
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 [amazon.com] 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".
Re:Not original but... (Score:2, Informative)
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
Re:In a nutshell (Score:3, Informative)
Or not.
Maybe there's no way people will pay $200 tax to use their computer, in the next 30 years.
Of course, if you addressed a new tech, like nanotech-for-the-regular-guy or stuff like that, there's room for some hobbist-turned billionaire, but regular software doesn't look like a field that could support another Bill Gates.