Skip to main content

bad design everywhere!

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.


Popular posts from this blog

Highly targeted Cpg vaccine immunotherapy for a range of cancer


This will surely go down as a seminal advance in cancer therapy. It reads like magic:

So this new approach looks for the specific proteins that are associated with a given tumors resistance to attack by the body's T cells, it then adjusts those T cells to be hyper sensitive to the specific oncogenic proteins targeted. These cells become essentially The Terminator​ T cells in the specific tumor AND have the multiplied effect of traveling along the immune pathway of spreading that the cancer many have metastasized. This is huge squared because it means you can essentially use targeting one tumor to identify and eliminate distal tumors that you many not even realize exist.

This allows the therapy for treating cancer to, for the first time; end the "wack a mole" problem that has frustrated traditional shot gun methods of treatment involving radiation and chemotherapy ...which by their nature unfortunately damage parts of the body that are not cancer laden but …

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache
The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform certain actions. Also, the…