I was not as productive today on my continued guest private message implementation as I wanted to be, I was just getting into the groove, lining up my wheels to the highway of efficient code when out of the blue came....
my nephew.
See, two days ago he mentioned that his pc was on the fritz, since his loving Uncle is the "pc guy", he came over to ask me if i could take a look at it. At the time I was just getting the implementation started and was very busy, I told him after a short moment of thought "Tuesday." Of course when he did show up, I was completely surprised to see him...long story short, I spent the next 5 hours reinstalling XP. This takes me to the subject of this post.
Microsoft (and many companies) are plagued by a problem of design of large technical products that has to do with the scale of the task that is exacerbated as the number of individual agents working on the tasks sub parts goes up. Take an operating system, Microsoft has several teams working simultaneously to design their operating systems. Outwardly it might seem that having multiple teams working at the same time will drastically reduce the time needed to complete the entire task BUT it comes at the cost of necessarily reduced quality. The quality reduction comes from the fact that at each interface between the teams (and within teams ..interface (or interaction) between developers on the team) there is a loss of information or a difficulty to transfer information critical to ensuring that the finished whole works efficiently. The use of object oriented programming methods in theory is supposed to stream line the component based design that is critical to making software work efficiently and with as little code as possible BUT when you have that design process interrupted by different teams , with different class design strategies (using sometimes different tools), the big picture tends to get cluttered away with gunk in code. This gunk is what leads to the miscellaneous kludges that must be added to fix the slight (or major) disjoints that occur when the many different components of a large design are sewed together, like some impossibly large and complex patchwork quilt.
A particular item of observed bad design that piqued my annoyance concerned what I considered easily fixed UI problems. The XP OS dialog for turning on and off the firewall and windows update had a nice graphical illuminated button , all ready to be pressed. Of course pressing the button does nothing...instead , you must scroll the panel down to links to disable or enable the features. I wondered why wouldn't they just allow the buttons to be depressed? The user is expecting that intuitively due to the graphical paradigm employed yet instead a more complicated process was created to perform the task. The next item was more dangerous, it involved the messenger service of windows XP, which as most people familiar with windows XP knows is turned on my default. The amazing thing was that within seconds of installing the computer to the broadband network I received two different messages that claimed that my registry was corrupted and that I should go to a specified web site (not microsoft of course) to download the "fix". We all know what that was, a network delivered piece of malware that identified and sent a messenger service message to the pc within seconds of it being online. I can't imagine how many pc owners are upgrading XP at this moment, are getting that message from their local network and then are studiously clicking "ok" to download the rootkit/malware onto their computer. All this happening simply because of Microsoft's bone headed decision to install windows XP with the messenger service (as well as other exploitable but rarely used services) turned on by default.
The bright side of bad design though is that when it is found, it should be taken as an opportunity to solve the problem with the right solution or go build a company around doing the same. If we hone our ability to detect the whiffs of bad design that pollute the world of goods and services in which we are embedded and simultaneously engineer good design we can put ourself in a place to profit from it.
my nephew.
See, two days ago he mentioned that his pc was on the fritz, since his loving Uncle is the "pc guy", he came over to ask me if i could take a look at it. At the time I was just getting the implementation started and was very busy, I told him after a short moment of thought "Tuesday." Of course when he did show up, I was completely surprised to see him...long story short, I spent the next 5 hours reinstalling XP. This takes me to the subject of this post.
Microsoft (and many companies) are plagued by a problem of design of large technical products that has to do with the scale of the task that is exacerbated as the number of individual agents working on the tasks sub parts goes up. Take an operating system, Microsoft has several teams working simultaneously to design their operating systems. Outwardly it might seem that having multiple teams working at the same time will drastically reduce the time needed to complete the entire task BUT it comes at the cost of necessarily reduced quality. The quality reduction comes from the fact that at each interface between the teams (and within teams ..interface (or interaction) between developers on the team) there is a loss of information or a difficulty to transfer information critical to ensuring that the finished whole works efficiently. The use of object oriented programming methods in theory is supposed to stream line the component based design that is critical to making software work efficiently and with as little code as possible BUT when you have that design process interrupted by different teams , with different class design strategies (using sometimes different tools), the big picture tends to get cluttered away with gunk in code. This gunk is what leads to the miscellaneous kludges that must be added to fix the slight (or major) disjoints that occur when the many different components of a large design are sewed together, like some impossibly large and complex patchwork quilt.
A particular item of observed bad design that piqued my annoyance concerned what I considered easily fixed UI problems. The XP OS dialog for turning on and off the firewall and windows update had a nice graphical illuminated button , all ready to be pressed. Of course pressing the button does nothing...instead , you must scroll the panel down to links to disable or enable the features. I wondered why wouldn't they just allow the buttons to be depressed? The user is expecting that intuitively due to the graphical paradigm employed yet instead a more complicated process was created to perform the task. The next item was more dangerous, it involved the messenger service of windows XP, which as most people familiar with windows XP knows is turned on my default. The amazing thing was that within seconds of installing the computer to the broadband network I received two different messages that claimed that my registry was corrupted and that I should go to a specified web site (not microsoft of course) to download the "fix". We all know what that was, a network delivered piece of malware that identified and sent a messenger service message to the pc within seconds of it being online. I can't imagine how many pc owners are upgrading XP at this moment, are getting that message from their local network and then are studiously clicking "ok" to download the rootkit/malware onto their computer. All this happening simply because of Microsoft's bone headed decision to install windows XP with the messenger service (as well as other exploitable but rarely used services) turned on by default.
The bright side of bad design though is that when it is found, it should be taken as an opportunity to solve the problem with the right solution or go build a company around doing the same. If we hone our ability to detect the whiffs of bad design that pollute the world of goods and services in which we are embedded and simultaneously engineer good design we can put ourself in a place to profit from it.
Comments