Forgive the non-technical post and the language, but this has me a bit upset.
There is nothing I hate more than to see millionaires complain about money problems. NASCAR is apparently having some difficulty with their races due to the recent gas hike. My favorite quote was:
“We also are seeing it in our aircraft. Our charter company, because we charter our team planes, has given us an extra charge directly due to the raise in fuel costs.”
Well boo-f ‘ ing-who.
I don’t know if anyone caught the Washington Post story a few days ago titled “Hackers Attack via Chinese Web Sites“. It seems to have slipped past everyone in the news. Of course, The WP has become so disreputable and biased that it shouldn’t surprise me that no one paid attention. However, we were warned well in advance, so it should be no surprise.
This begs the question, however. The government has to be, without a doubt, one of the largest consumers of computer goods and services. While I am not an advocate of increased tax spending, this area could use some. Perhaps its time to take a different approach with that spending, however. We have tried many things over the years: Internet War Games, hiring our own elite forces, and even creating more laws and policies. These are certainly deterrents, but security in depth is the key here.
Any good football team has a good offense, a good defense, and a great different game plan depending on who their enemy is. We have the offense now (as mentioned above), we have ‘some’ defense as well. Laws do us no good when dealing with hackers in foreign countries. So what is the answer? I will not purport to have that ‘nail in the coffin’ answer to cyber terrorism and anyone that claims they do is selling you a bill of goods (And they will typically have the abbreviations “Sen.” or “Rep.” in front of their name). However, there are a few other things we need to explore. One mark of a great football team is that they have the ability to surprise and misdirect their enemy. Making the opponent attack in the wrong direction has often led to victory in some of the best games I have seen played. In IT, the misdirection can be supplied with honey pots and misinformation. We can take a trip from the tabloids and start putting out information that sounds correct and feasible, but is nothing more than fodder for the masses. For instance, sending out communications that will most likely be intercepted to “expose” a weakness that is actually a strength can cause a huge failure on an attacker.
This is also not a new concept in typical warfare. Many of you may remember the move “The Patriot”, which was a loose description of the revolutionary war battle in Cowpens, SC, made use of a “double envelopment” strategy, which essentially used a perceived weakness to entice the enemy into a trap. Obviously, this was not the first use of the strategy either, but is highly notable due to the movie’s popularity. Honey pots and misinformation are highly useful in this same context. We strengthen what we may now understand is a weakness, and then taunt the enemy with the weakness again. While the enemy attacks, we have a better chance of pinpointing their location, and perhaps sending them a nice drone-delivered “ACK” to their received packets.
The football analogy works to some degree when trying to put together a cyber security policy. However, we do not “play” against one enemy at a time. We play every team out there — known and unknown. This is why defense is our most important aspect of policy. Our defense needs to be highly educated, state of the art, and driven. We have no way of knowing who is going to attack and when. There is no way we can be prepared for every attack possible. However, we can at least provide some misdirection while we shore up our defense and plan our counter-attacks.
The other day, I posted an article about Engeneering for Usability. I hadn’t intended to make a series of this, but it may very well turn out that way as today’s post is about engeneering for reliability. Who knows what future posts may hold.
I was sitting in a doctors office the other day, waiting very patiently to be called in. I fidgetted as I always did. Leaning forward, leaning sideways, flopping around like an idiot just trying to reconcile myself with the fact that I didn’t have a laptop or something in front of me to do. But then it sort of hit me. I was abusing that chair to death and it was taking it.
Lets think about the first sentance of this blog post. I said that I was sitting in the doctors office. I’ll bet not one person reading this said “Oh man, what kind of chair was it?” or “Oh my goodness, what if it breaks?” or “Holy cow, that guy is really rolling the dice there isn’t he?”. All of you most likely pictured someone just plopped down on a chair. No one was really fixed on the idea that the chair could fall apart or that it wasn’t an appropriate height. The reason behind this is that, in general, we tend to think that a chair will work when we use it. When was the last time you tested a chair to see if it would hold your weight? I’m sure under the right circumstances, you just might — like if the chair looked visibly weak or damaged, but once again, the general concensus is that its going to work out for you.
When was the last time you could rest this easy with the software we use on our desktops? Do we ever hear someone talk about a piece of software crashing and say, “wow, that’s unusual”. No, in fact, many computer vendors design their software to handle crashing more gracefully. Microsoft themselves have implemented the ability to report errors to them that occur (with a prompt to the user, of course). We have event logs, log files, dump logs, and the like. As developers we spend more time preparing for our software to crash than I think we should sometimes spend making sure our software doesn’t crash to begin with. But while we should spend a great deal of time testing and thinking through our applications — making sure they can work, that isn’t even half of what is required to develop a reliable software system. There are things that are out of our control such as network connectivity, power failures, hard drive crashes, and other hardware failures.
For these very reasons, desktop software most likely never will be as reliable as a chair — its too dependant on too many things in the environment. We have to depend on outside influences such as universal power supplies, raid controllers and backup network connections. These are not typically all seen in your typical home system and even if they are, you can’t make those things prerequisite to installing your software because your available user base would sink considerably. The chair, on the other hand, has everything it needs on hand to appease its user base. Despite the fact that there are a million chair varieties, they all come with their own support system and don’t depend on anything but gravity to make it work right (there’s that gravity constant again).
When it comes to desktop software and even small business applications we are forced to plan for and handle as many failures as we can forsee. We have to accept the fact that outside influences such as memory corruption and IO errors may cause our application to misbehave. Obviously with enterprise software, the guys with the big bucks pay us to implement systems with hardware failovers, double, tripple or quadruple redundancy, and the like. We can make most of those applications truely reliable and nearly as reliable as a chair. However, till we see Dell shipping every system out the door with a UPS, backup and restore operations, RAID and free connectivity to multiple providers, prepare your applications well to handle these errors.
So what can you catch? What can you do to make the user trust your application in spite of these obvious physical problems?
These certainly isn’t a comprehensive list, but it should be enough to get you started. You’ll never be able to meet the same reliability standard of a chair with software, but you should be able to instill confidence in your application’s users. Let them know that they can “sit back and relax” knowing that you, your application and their chair will be there for them when they expect it to be.
Today, I used a vending machine. Anyone that has met me will surmise that this was obviously not my first attempt to purchase an unhealthy snack from such a contraption. In fact, not only have I excessively used of vending machines, I’ve written code for kiosks that use the same currency and coin accepting hardware as vending machines. Suffice it to say this long paragraph was meant to proclaim my self-appointed title of “Certified Vending Machine Professional” (CVMP).
However, with all of my years of experience, today’s experience was different. Today, I approached the vending machine, tired from lack of sleep the past month, distraught over having to get my cat a permanent tracheotomy, cranky from a back problem, and distracted by tons of work-related issues running through my head. I carefully stood in front of the machine contemplating what I would get this time — as though the product selection would have changed between now and the last time I looked. Well, I am supposed to be on a diet, but due to the massive amount of life-issues I’m having at the moment, I decide a “healthier” vending machine snack of pretzels will suffice this time. “D10, 65 cents, ok.” I think to myself as I begin to press the numbers out on the keypad “D, One, Zero — CRAP!”. As it turns out D-10 expected me to press D and then press a key they had specifically set to 10 — not 1 then 0 as I was thinking. I knew this. I’ve used enough vending machines in my life to know how they work. But today, I failed the test. I immediately began to blame the vending machine and started re-engineering a smart vending machine in my head.
Here were the problems I saw with the current design.
The “lets design something cool” personality in me immediately started thinking about solutions to this problem.
But then the “practical architect” personality interjected with complaints to these solutions. First off, lets think about this. Who is the customer of a vending machine. Was it me? Surprisingly, no. The vending machine “customer” was the company who bought it with the intent to make a profit from it. Sure, I may use the vending machine, but ultimately, its the vendor that wants the mechanism that accepts payment and dispenses product. We unwittingly provide our services as testers of the product and give feedback on it (based on our use or non-use of the product). That whole argument is reserved for another post though. Blindly accepting my argument that the vendor is the customer of a vending machine, your next question is to ask, what are the vendor’s requirements for the machine.
Using a lose set of some of those spiffy PASS MADE criteria from the MSF exam (70-300) for your MCSD, lets take a look at those requirements.
So lets apply these characteristics to my “solutions” from above. We’ll find out these were not solutions at all, but fixes to perceived problems from a single-minded personality. My Architect (as I’ll refer to that voice in my head), says this.
The product isn’t on a belt because the time spent between asking for the product and obtaining it could potentially take a lot longer (Performance). The keypads were not arbitrarily placed at waiste level to tick me off, they were blatantly placed there to provide easier accessibility to those who are height-challenged or otherwise requiring accessibility. The credit card reader isn’t placed on the machine because it would be too easy to intercept. These vending machines can be placed anywhere, and sometimes in really poor choices (rest areas, for instance). While having a vending machine broken into would be bad, having credit card data compromised from one of these locations would be worse. (Security) Placing the items on a belt would make it harder to provide additional items in the physical range of motion of the device. It would be harder to add more product to the machine this way — and much more expensive (Scalability). Those devices would also have a large amount of moving parts that could break. Putting the keypad on a moving device as well as the product would reduce the useful life of a vending machine while raising the cost of it — bad for any investment. It would also be susceptible to significant breaks and massive amounts of upkeep (Maintainability). Putting these items in a bad area would be an even worse move. They would be much more expensive to replace and fix if someone vandalized them — much more, that is, in relation to a simple spring delivered product dispenser that relies on gravity to get the product to its location. The parts would definitely have a much higher dead-on-delivery rate than normal vending machines — causing massive replacement shipping/delivery costs (Deployability). This is a stretch, but by placing additional overhead on these machines, you actually reduce the available room to provide additional hardware to the machine. You could be restricted to a smaller area and some additional hardware may interfere with other pieces of hardware causing more issues than it solved (Extensibility).
Availability, therefore, seems to be the only area that I wouldn’t have negatively impacted by my decisions for a vending machine. As software engineers, we need to make sure we aren’t over-engineering our products. Many times the “cool” solution isn’t the right solution. For instance, the delivery mechanism, while annoying for anyone that is tall or has a back problem, is fairly consistent. I mean, who has a better system than gravity? Last I saw it was a constant! Sure, occasionally product gets stuck in the machine before gravity can do its part, but I guarantee the mechanical delivery system would be much more prone to mistakes than the simple “twist and drop” method of most vending machines. While I may have potentially solved “my” problems, I’ve caused many more for my real customer — the vendor. In actuality the dependability of my vending machine would have cost more money to purchase and maintain, caused dependability problems due to mechanical failure, and most likely annoyed everyone more than “New Coke” ever did.
Yes, its great to solve your problems in cool ways, but make sure the problems you are solving are for the right person and actually advance your product design before adding more features than are necessary.
So now you can now send kids to prison and charge them with felonies when your security is so lax that they can waltz in. Here’s the long story.
Here’s the short story.
A school handed out Apple iBooks to 600 students in a school. These laptops had various “security” features on them to keep them from accessing parts of the internet, or installing anything. They also had monitoring software that allowed a school administrator to see what was being viewed on the student’s laptop. I appologize that I don’t know if the software was custom made or if it was a known package. In any case, the password used to bypass these features was foolishly taped to the back of the laptops.
Using this password, the kids bypassed the software so they could download iChat to talk to each other. They also reportedly turned the tables on their school by monitoring the administrator’s desktops instead of the other way around.
This is typical childhood behavior. Kids are currious and given the opportunity to explore, they are going to do so. Given a challenge that they “cannot do x”, they will do x, y and z to prove you wrong. As the kids pointed out, and I oddly enough agree with the kids for once — the punishment doesn’t fit the crime. I’ll go one step further to say the punishment doesn’t fit the right people. Those involved with the “security” of these systems need to be shot. We’ve had examples of disobience to simple rules that date back to Adam and Eve and a simple piece of fruit. What makes you think that history will somehow change itself and kids will simply obey an order? If they are curious, and you leave the door open enough to fit their fingers through, they will find a way in.
In my mind, the correct response to this would be to give them a slap on the wrist for the disobedience, put the kids in some sort of programming course , nurture their natural abilities, sack the programmers who wrote the systems to begin with, and charge the kids with designing a better system. To me, that’s education!
OK guys and gals. Some pretty big names are rolling into Charleston on Saturday, September 17th to present, free of charge, all those fancy topics we love to yap about so much. This is Charleston’s first code camp. Chris Williams tells me that enrollment is low. What would it take to persuade a few more folks to take a nice weekend trip to a college/beach town, watch some cool technology in a demonstration and go have a few drinks?
Check out the sessions and the speakers. If you don’t find anything you are interested in, come anyway and enjoy the beach with your fellow geeks! Please register quickly!
Since I ended up on the INETA Community Launch Team, I guess I should start promoting a few things about Visual Studio .NET 2005 and SQL Server 2005. After all, it can’t ALL be about JAXASS (Javascript And XML Accessing Services Simply) , can it? Let me start by pointing you to this new tidbit from Microsoft. Its an awesome play on some well known comic movies of the past called Escape From Yesterworld. Prepare to spend a little time there, but be prepared to laugh int he process. Someone sunk a LOT of time into this promotion video/site, so the least you can do is click on the main page and check it out.
I’ve been talking with a few people recently about COmega, C# 3.0, C# 4.0 and the like. On top of that, I try to get my hands on anything “new” that I can well before it becomes of interest to the general public. I keep getting asked why I like to sit on the razors edge (or at least pretend to). I usually tell them its because its the only way that I can continue to remain creative in this field. The rest of this post articulates my rationale behind this idea.
I’m definitely a child of the PC computing industry. I’ve grown up around computers. I’ve seen one innovation after another. I have to say the most amazing times in my programming life have been spent hunched over a computer all night hacking out a new way to solve a problem. Even later in my professional career, during the “high-tech late 90’s” I had a blast playing with xml data islands before example one hit the list server (wow, does anyone remember learning new concepts on list servers? yikes I feel old). Whatever the case, what was interesting was that everyone was learning something new because everyone was solving technology problems on their own; sometimes for better and sometimes for worse. But every programmer had to learn to be creative to solve problems.
In recent years, the big push is to standardize technologies at the earliest possible moment — locking most programmers into one way to solve a problem. Failing to follow the standard usually lands a host of glaring architect eyes on you. You can bet if you do come up with a new way to do something, someone is already trying to create a standard to the contrary; again, most times for the better and sometimes not. Sometimes those standards, at least initially, fall far short of being a good solution for more than a handful of people (i.e. WSE). But as more people jump on board, those standards morph into something more usable by others (i.e WS-* added to WSE-n). Sooner or later, design-time components are emassed by third-party companies like a bad mildew stain around these standards. We are all sort-of stuck using those tools and those standards until Microsoft decides to devour that component industry and write their own wrappers around the standard.
There are only a handful of people who then have any say on the standard and the self-proclaimed “right way” to do things. Sure, these standards do let us focus more on solving the business problems instead of technology problems, but who wants to do that? We can sit back in our spare time and “play” with our own solutions, but when you get back to work in the morning, its back to WSE-2, RSS,
I do understand the benefits, so don’t get me wrong. I’m so much happier to have a tool generate my WSDL , at least from a starting point, than for me to do it myself. I do get to look at some other cool technologies because I can look past some of those questions that the standards answer for us. However, with all the real benefits that standardizing brings to us, there are times when I miss having the freedom to innovate on my own without looking how everyone else does it first.
That is the treaty that the business folks have signed with us geeks — we get to play with their expensive toys and data centers but only if they get to make us “more productive” with standards bodies.
I’m still sitting here with my back in agony but working on some very cool projects. As you’ll notice my post count has dropped each month, slowly but surely. I hope you don’t hold that too much against me. Forgive the dorky analogy, but I have too many threads executing in my life right now and not enough time slices in the day to handle everything and blogging without reaching my saturation point — the point where context switching takes up more time than is effective to execute my processes. Unfortunately, I’m running under more of a cooperative model and these project schedules don’t neccessarily play nice-nice with one another. Between work at TiBA, projects for Microsoft, book writing, investigating features of CO and SXM, learning some lower-level programming to keep up with the Jones’, putting together a new presentation for Code Camp in Charleston, and presentations for multiple guild meetings (October, November, December), posting a few answers here and there on the forums, I don’t have much time to myself. Blogging, therefore has had its thread priority set to below normal.
Speaking of cooperative threading, I’m proud to say that my recent eBay addiction landed me a brand-spanking new copy of Windows 3.1, MS-DOS 6.2 and a MS-DOS 6.22 upgrade (no Windows 3.11 upgrade yet). These copies are sealed and even still have a part number sticker on them from the large computer manufacturer these were sold by (OEM). They will go in my museum of artifacts. I am having a bit of buyer’s remorse though. I’ve spent too much money on useless things like my ATARI 800XL which I fully expect to be here a couple of days after the July 4th holiday. This too was a brand new system (appears new and unused).
Anyway, enough babbling for the night.
For two weeks solid, I’ve been stuck in some sort of zombie mode. I’ve been unable to sleep for more than an hour at a time, or not at all some nights. I have had some major back pain in the past week and a half too so that may have something to do with it. But as I sit her ein my computer nook at my baren apartment, I find myself wide awake but unable to concentrate enough to do anything constructive. I try doing my work and I cannot. I try taking a couple unisome and laying in bed, instead I feel like I’m on some sort of acid trip. The type of sleep that unisome attempts to induce is something very strange to me. Its like the drugs are trying to “trick” me into falling asleep. It may sound slightly crazy, but I’ve somehow conditioned myself to get wide awake when I feel I’m being tricked. So taking unisome just makes me feel very strange, but even more awake. I’m not anxious about anything. I’m not taking on more or less work than I usually do. I’m just, awake and in pain from my back.
I’ve tried everying I can think of and its getting worse. Does anyone else get this way?
