Does Vista Suck if it is Not Vista?

Interesting post over on Ars Technica – Microsoft does a blind test with Windows XP users, telling them that they are testing a new OS. It is really just Vista. And the overwhelming majority are impressed.

As I have said frequently before – Vista’s problems are (for the most part) not technical – they are marketing and perception. It reminds me of a term from (I think) Tom Peters in Thriving on Chaos – “relative percieved product quality”. It is not the true qualty that drives consumers, it is all about perception.

Thoughts in the Middle of the Night

I am just coming off an all-nighter – it has been a long time since I got so wrapped up in coding that I worked all night.

After I got to tired to code effectively, I got reading some blogs and thinking on various topics. One the things I was thinking about (obviously not for the first time) is the whole open source software movement. As always, there is a fair amount rhetoric out there regarding the superiority of open source software, the TCO of OSS applications, the advantages of development under the open source model, etc., and even conjecture about the ultimate demise of all non-OSS development.

A number of questions have always nagged at me about the claims of OSS:

  1. Believers frequently claim that OSS produces better software, with “better” defined in various ways – fewer defects, better functionality, more secure, etc. Is there empirical data to support this on a broad scale? Yes, there are examples frequently given, but usually it is a comparison of one or more highly successful OSS project against one or more bad examples of commercial, closed-source applications. Is there any broad, unbiased comparison of large numbers of OSS projects to large number of non-OSS projects?
  2. Similarly, Believers often claim that the process of open source development is much more efficient, effective, and innovative that its non-OSS counterparts. Again, OSS success stories are frequently compared to horror stories form the non-OSS world. Is there any large scale, unbiased comparison out there? For example, it is often quoted the a very large percentage of software projects are late, over-budget, or complete failures. Is the open source world any better? People always talk about the successes of OSS, but take a browse around SourceForge some time – there are a huge number of projects there that are never completed, never deliver anything, never get past Alpha, etc. The OSS statistics always seem to be somewhat selective.
  3. Many people predict the demise of closed-source development (and have for a long time). Are there any clear statistics out there as to the number of developers working on OSS versus non-OSS development (I know, many do both). Or is there information as to the economic force of OSS versus non-OSS – how much economic activity in the IT world is driven by OSS?

I don’t have answers to any of these right now – just some thoughts which occurred to me through the night – hopefully I will have time to dig deeper into this over the next while.

Rumor: Tablet Mac to appear this fall

 

Rumor: Tablet Mac to appear this fall

I agree – competition is good, and anything which livens up the Tablet market is also good.

The depressing thing is, shortly after Apple releases a Tablet, the whole world will be proclaiming how cool and hip Steve Jobs is for inventing the Tablet computer.

Is eMail dead?

I have always been a big fan of email (well, since email became prevalent, anyway). For me, it is a big help to be able to interact with people asynchronously – to be able to send questions or requests and let people deal with them when they have time (and them to me). This as opposed to a phone call or walking over to their office and demanding immediate attention, and interrupting whatever they are doing. I know not everyone shares my views on this. My peers at Whitehill felt pretty much the opposite about email – that it was a medium of last resort, and that face-to-face or phone communication were preferred. As with most things, I think the real answer is in balance and using the right tool for the context.

More and more, however, I am finding that email has become less useful. As a way of distributing specific documents within a team, it is still good. Same for setting up meetings. However, I have noticed a trend over recently (or longer than recently) for people to just ignore email. For the most part, unless a message is marked urgent, or is part of a project-specific interaction, I receive responses to only about 20% of email. I find it hard to believe that this could all be because of poor email etiquette (mine or others). I suspect the bigger problem is email overload – most of us receive far more email than we can possibly respond to. Perhaps email was more productive before it became so widespread. Then there were the years of spam overload, causing many to give up on email as a useful tool. Now (for me, anyway) email spam is no longer a problem. However, many people are still overloaded, even with spam eliminated.

So, is email as a useful business tool dead except for limited communications on projects?

Interesting article on the "OS Wars"

This article from PC Magazine is interesting. It does a fairly good job of looking at the pros and cons of various OS’, without the silliness of most such discussions. The only aspects of it I think are a little unfair are the “Price” and “Installation” scores, both of which rate Mac OS better than either Windows XP or Vista.

On the price side, while it is true that you can buy Mac OS for less than Windows, you cannot (at least if you are a typical user) install it on your existing, non-Mac hardware. So the true cost of a typical user switching to Mac OS includes the cost of buying a completely new computer, at a premium price.

On the installation side, again the comparison is not quite fair. Both Windows and Linux are general-purpose OS’ which have to be able to install on a wide-range of hardware and almost unlimited permutations of hardware configurations. Again, Apple does not have this problem with Mac OS, since Apple tightly constrains (though not as tightly as it used to) the hardware configurations with which Mac OS must contend.

Overall, though, not a bad article.

Is Software High Tech? If not is it a Commodity?

I was reading Is Software High Tech? If not is it a Commodity? « Tech IT Easy. It struck me that the question is not entirely meaningful. I agree with the statement “software by itself is no longer high-tech.”

However, the same question may be asked of many other aspects of technology. Take electronics, for example. There is no denying that there is a great deal of electronics which is obviously “high tech”, but being electronic is not, by itself, is not enough to make something high tech. Is a transistor radio high tech?

In the same way, there are many, many kinds of software out there which are decidedly not high tech (including much of the web). This is not to say they are not innovative – being innovative is about much more than the technology.

ASUS’ R50A UMPC goes legit – Engadget

Post on Engadget about the new ASUS UMPC. It is interesting that the main complaint they have (and many of the comments agree) is the “lack of a QWERTY keyboard”.

When are people going to grasp that the whole point of this form factor is to not have a keyboard? Of course, people predicted doom for the iPhone because it did not have a keypad, but Apple was smart enough to point out that that was the idea. People are so locked into one way of interacting with their hardware that they cannot think beyond it. I went through the same thing when I got my first slate Tablet PC. At first, everything I tried to do seemed extremely cumbersome and awkward. I was constantly hooking up a keyboard and mouse to create eMail and documents. Then I got rid of all my other computers, and my keyboard, and my mouse, and tried to work entirely within the Tablet paradigm for a couple of months. What happened is that I discovered that how I did things on a laptop did not work well on a pure tablet. In addition, there are things that a pure tablet is good for, and there are things it is not. For example, I find the Tablet extremely useful for:

  1. Taking notes and leaving them in hand-written form (using OneNote)
  2. Brainstorming with tools like MindManager
  3. Reviewing and marking up documents in ink (using Word, or PDF Annotator)
  4. Reading eMail, and responding, if I want to send a written response (anything more than a few lines is inconvenient to do with the TIP)
  5. Web browsing for research (and sending results to OneNote)
  6. Reading eBooks
  7. Watching video contents
  8. Dictating documents (if you have good microphones, and enough processing power)
  9. Delivering Presentations (with the ability to annotate slides on the fly, save the annotations, and distribute the marked-up slides)

Things it is not great for:

  1. Creating long documents or eMail in text format.
  2. Creating presentations without dictating
  3. Anything which would normally be done with a lot of typing – again, any amount of text input using the TIP is a pain.

What it comes down to is that Tablets and UMPCs are very useful without keyboards, but not for everything. That does not mean that they should have built in keyboards – it means they should be used for what they are good for.

Christmas Break time

Time to take a few days off. I do not plan to post anything over the holidays – in fact, I intend to avoid being online to the greatest extent possible.

Also note that I will probably not be on reviewing comments either, so if your comment does not get moderated/approved right away, do not assumed I have rejected it. I probably just have not looked at it.

Cheers, and Happy Holidays. Enjoy time with your families, and whatever deity you’ve chosen (or not 🙂 ). Remember that none of this technology stuff is that important, and remember what is.  

Fred’s Law #2: Requirements, we need lots of them!

As I have already said, doing away with requirements altogether is a really, really good way to ensure that your project will fail in a spectacular way.

Another really good approach to being bad is to try to capture every possible requirement that anyone might ever want, ever. There are a number of advantages to this approach as compared to the “no requirements approach:

  • You can create the illusion that you really know what you are doing
  • You look like you are being extremely diligent
  • You always look like you are extremely busy
  • You create huge amounts of documentation to support the illusion that you have been both busy and diligent

Unfortunately, you may never actually get to the end of the requirements gathering process. If you do, you will probably either have missed the window of opportunity on whatever you wanted to build, or you will have produced a set of requirements so convoluted that no one will ever implement them.

On the upside, you will have greatly reduced the risk of the actual development failing, since you probably will never get there. You will save huge amounts of money on developers, as well as computers and tools for them.

So you never actually have a product to sell, or software to use. You will have done your job well, it will not look as though your project actually failed, and it will look great on your resume as you look for a new job.

 

Share this post :

 

Fred’s Laws #1: Requirements, who needs ’em?

Well, I guess it is fitting to start out Fred’s Laws at the beginning of the process – with requirements.

If you really want to start of on the right foot, and get your project well on its way to a spectacular flame out, this is a fantastic place to start. Remember, the best way to figure out what your software needs to do, how it should do it, and what it should look like, is to get your coders right in there coding. After all, who knows what the user wants better than coders?

This is especially true if you are building something new and innovative, or if you are short on resources or time. Just think of all the time you will save by not having to talk to users up front. And, all those resources you would have wasted talking to users can be redirected to more important things like coding (whether they know how to code or not). Just imagine how far ahead of schedule you will be right from the beginning!

Now, estimation and scheduling may be a challenge without some definition of what you are building, but you probably will not be doing any real estimation or scheduling anyway (see later laws). If you need to have estimates and schedules to show to management, you can always make something up out of thin air (but make sure not to talk to your developers about it!).

(and just think how much time you will save talking to users later on, since you won’t have any!)

To be really specific, make sure you avoid any of the following activities, which are known risk factors which could lead to success:

  • Set up a system for capturing requirements, using Access, Excel, file cards, or any other tools
  • Establish a process to review and prioritize requirements, and assess their value versus cost
  • Define a process for managing changes to requirements
  • Involve users or user representatives in the creation and/or review of requirements

All in all, avoiding requirements definition should save a great deal of time up front, and allow you to focus on the important work of trying salvage your failing project.

Share this post :