Forgot your password?
typodupeerror
Software Editorial

Six Laws of the New Software 313

Posted by CowboyNeal
from the listen-to-the-law dept.
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."
This discussion has been archived. No new comments can be posted.

Six Laws of the New Software

Comments Filter:
  • In a nutshell (Score:5, Informative)

    by winkydink (650484) * <sv.dude@gmail.com> on Thursday February 03, 2005 @09:45PM (#11568757) Homepage Journal
    Keep it simple
    Keep it small
    You're not gonna be the next Microsoft
    Do many releases
    Comply with relevant standards
  • Direct link (Score:4, Informative)

    by Dancin_Santa (265275) <DancinSanta@gmail.com> on Thursday February 03, 2005 @09:49PM (#11568797) Journal
    Link to article [changethis.com]

    Be careful, it locks up Firefox until it loads.
  • by Anonymous Coward on Thursday February 03, 2005 @09:51PM (#11568811)
    Actual pdf [nyud.net]
  • pdftotext (Score:5, Informative)

    by flossie (135232) on Thursday February 03, 2005 @10:03PM (#11568878) Homepage
    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
  • by QuestionsNotAnswers (723120) on Thursday February 03, 2005 @10:13PM (#11568928)
    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!
  • by Anonymous Coward on Thursday February 03, 2005 @10:14PM (#11568932)
    If you look closely, the bug uses a workaround trick to get the pages rendered correctly. If it rendered it correctly in the first place, they wouldn't need to worry about this.

    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.
  • by Anonymous Coward on Thursday February 03, 2005 @10:26PM (#11568991)
    I believe the term you are looking for in sending output of one program to another is "piping."
  • by sglider (648795) on Thursday February 03, 2005 @10:26PM (#11568994) Homepage Journal
    This link from the Firfox FAQ [mozilla.org] answers why that happens. It isn't Firefox's fault, but it is adobe's fault. If you follow that link, you'll see adobe pages load (on a broadband connection) in mere seconds.
  • by Anonymous Coward on Thursday February 03, 2005 @10:35PM (#11569032)
    Read the bug report. The 100% valid HTML sample renders incorrectly. This is a Firefox bug.
  • by Anonymous Coward on Thursday February 03, 2005 @10:48PM (#11569110)
    I use GSView. Clears up the problem nicely(though PDFs don't always work QUITE the same way)
  • by ufnoise (732845) on Thursday February 03, 2005 @11:14PM (#11569226)
    Disable the acrobat plugin.

    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.

  • by dabigpaybackski (772131) on Thursday February 03, 2005 @11:17PM (#11569238) Homepage
    Disable the acrobat plugin.

    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.

  • by Anonymous Coward on Thursday February 03, 2005 @11:22PM (#11569262)
    You ideas sound intriguing. How can I subscribe to your newsletter?

    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.

  • by dmaxwell (43234) on Thursday February 03, 2005 @11:53PM (#11569404)
    The plug-in is itself Adobe software. It would be nice if there was such a thing as a plug-in system that can't be abused but I suspect that it either doesn't exist or isn't practical. I've been using Mozplugger to invoke Acrobat. The behaivor is much better. Mozplugger will start a new instance of Acrobat for each PDF you open in a tab but it seems to sidestep the other ills caused by Adobe's plugin.
  • by ytpete (837953) on Friday February 04, 2005 @01:43AM (#11569792)
    An even better option: PDF SpeedUp [acropdf.com]. A coworker clued me in to this great little utility. It basically disables all the extra junk in Acrobat Reader, cutting the load time down to 1-2 sec tops.
  • by jalefkowit (101585) <jasonNO@SPAMjasonlefkowitz.net> on Friday February 04, 2005 @02:23AM (#11569921) Homepage
    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.

    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:

    I hear you. But I think the comparison is not apt. The right comparison is to compare our PDFs to books.

    Books are not searchable. They cost money to reproduce. You can't print multiple copies and Google searches them even less well than they search PDFs.

    You don't hear anyone whining about books...

    Anyway, we use PDFs because they're a lot more booklike. They read better. They stick together when you forward them. They print better.

    Maybe he should have just gone all the way and printed them as books, then?

  • Re:In a nutshell (Score:3, Informative)

    by robertjw (728654) on Friday February 04, 2005 @02:42AM (#11569992) Homepage
    Microsoft should read this article. Sure they have unstoppable vision and play to win, but they lose way more than they win.

    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.
  • by Leo McGarry (843676) on Friday February 04, 2005 @03:17AM (#11570095)
    This old saw needs to die, now. It's completely false to say that "the whole graphics subsystem is built on PDF." That simply isn't so. Let me explain where that came from.

    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 ...and that's with antialiasing and transparency. It's pretty amazing.

    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
  • by AhaIndia (725879) on Friday February 04, 2005 @04:25AM (#11570309) Journal
    This isn't Firefox's fault. It is because of Adobe products.
    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.

  • by hummassa (157160) on Friday February 04, 2005 @05:30AM (#11570442) Homepage Journal
    The point is: there will be no next Microsoft. So, it won't be you. Got it?
  • by JaredOfEuropa (526365) on Friday February 04, 2005 @06:15AM (#11570541) Journal
    The article makes a few good points, but they're hardly insightful stuff. Come on... most of us could have come up with these things. The article defines what a good product should be, but as we all know, a good product does not a succesful product make. And conversely, a bad product may still become market leader. Ever seen the user interface to SAP, Cognos, Agresso/Unit4? These are all popular packages around here... despite their many shortcomings.

    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.
    You're not gonna be the next Microsoft
    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".
  • by bessel (824697) on Friday February 04, 2005 @07:25AM (#11570752)
    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
  • Re:In a nutshell (Score:3, Informative)

    by orasio (188021) on Friday February 04, 2005 @08:56AM (#11571027) Homepage
    Somebody has to be

    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.

If a camel is a horse designed by a committee, then a consensus forecast is a camel's behind. -- Edgar R. Fiedler

Working...