« January 2006 | Main | March 2006 »
February 15, 2006
I Wouldn't Be So Late If... (Part 1)
“Omigod, what happened to you?” asked my friend Jenny when we saw each other after dropping off our 4th-graders at school yesterday. My shoulder was heavily bound with a most impressive arm sling. It was throbbing like crazy, but the attention that my fancy sling garners me everywhere in town is almost worth it. Sympathy is a neat thing – everyone pouring love and attention at you after only one brief glance.
(By the way, Jenny Michaels MD is a top psychiatrist specializing in chemical dependency. Her husband Basil Michaels is one of the best plastic surgeons in Massachusetts. If you’re alcoholic and need a face lift, they’re the ones for you.)
I replied, “I was walking in the woods with my kids, when suddenly a large bear leaped out from behind a tree! I seized it in a death-grip headlock, and punched it in the nose repeatedly while yelling for the kids to escape. The bear gave a mighty struggle and as it tossed me left and right, I wrenched my shoulder. But you should have seen how I beat up that bear!! I gave it the biggest bloody nose you ever saw!”
Jenny was most impressed. It’s not every day you get to tell a tall tale like this one to a beautiful doctor, and besides – it sounds a lot better than “I slipped on the ice in my driveway while taking out the garbage, because I was in a hurry for a 9am conference call,” which is what really happened.
I read the radiologist report of my MRI to Basil (the spousal plastic surgeon) which described the injury in these words: “Laminar tear of the supraspinatus tendon. Complete tear of the subscapularis tendon with retraction. Medial dislocation of the long head of the biceps. Joint effusion. Large tear of the inferior glenohumeral ligament. Soft tissue edema/swelling of the axillary region. Bone contusion involving the greater tubosity region.” (Yes, this is what happens when you fall, twisting your arm behind your back 90 degrees, and dislocating the arm bone out of the shoulder socket, essentially tearing all the anterior muscles/tendons and ligaments off the bone.)
“Holy smokes,” said Basil. “You really tore it up! That sounds really bad!”
“Yeah I replied, but you should have seen the bloody nose on the bear. I’ll do anything to save my kids.” (I figured I still had a day or so to milk the bear story, before the embarrassing truth about the ice and the garbage pail really made its way around town.)
“Yeah, yeah, I heard. But it’s too bad about the garbage and icy driveway. I heard you had to postpone a big consulting engagement. Think of how many years you could have hired someone to put your garbage out for you with the lost income.” Basil must have read a few articles about outsourcing.
So much for milking the bear story. Basil knew that I had to postpone a consulting gig in Chicago so I could get the MRI. The client had shifted to Agile methods for its large projects and hired me to benchmark their time-to-market and quality improvement against productivity statistics from our worldwide database of 7,000+ completed projects. It was the first time I had rescheduled a client engagement in 18 years. All because I was in a rush to do too many things at one time. I hate when that happens.
They say that you teach best what you need most to learn. I once wrote an article entitled “I Wouldn’t Be So Late If I Weren’t In Such a Hurry”. The gist of the article is that trying to run at breakneck speed in today’s Internet Age can actually slow you down. Even if you don’t break your neck, you can really smash up your shoulder. I’ve seen hundreds of projects that have crashed and burned because managers try to cram too much work into too tight of a deadline. The attempt to accelerate too fast drives the team to things that result in self-destructive outcomes. After a while, the universe bonks you on the head, and forces you to slow down.
Why? Because there’s a rule in cosmos that says “There are times that 'fast' can actually be slow. If you stop to think about it, you can discover a hidden secret: slowing down just a little bit can actually allow you to go fast - without breaking your neck, or putting you on the sidelines from tearing up your shoulder.”
So there you have it… 
Posted by Mike at 3:46 AM | Comments (2) | TrackBack
February 10, 2006
Complexity Doesn't Scale
Last week, an excellent piece by my fellow Cutter Consortium colleague Ken Orr crossed my inbox. I decided to excerpt it here since it directly speaks to a subject near and dear to my heart: software complexity.
After reading this, you may want more access to insights from various Cutter authors like Tom DeMarco, Ed Yourdon, Tim Lister, Rob Austin and scores of other experts. We publish research on Agile methods, Outsourcing, Business Technology Trends, Benchmarking, and the like. Check out the Cutter Consortium website at www.cutter.com. Sign up for trial subscriptions by contacting us there. You'll be plugged in to some real interesting stuff!
Complexity Doesn't Scale
by Ken Orr, Fellow, Cutter Business Technology Council
Cutter Senior Consultant Tom Welsh asked in a recent Business Technology Trends Executive Update whether software development had gotten too complex. He asked for feedback, so here it is: the answer to Tom's question
is unquestionably "Yes," software development has clearly become too complex! While it is true that the software that people use today is more sophisticated, at least at the user interface level, the complexity of software development has clearly spun out of control.
There are plenty of villains in this piece. There are the hardware and software vendors who have pushed new generations of user interface, operating systems, and programming languages while largely ignoring business analysis, requirements, and design. And there are the software developers who, until many of their jobs were swept away by outsourcing, were so enamored with the latest bells and whistles that they lost track of delivering high-quality, easy-to-maintain software.
There are also the software tool vendors who stopped working on Computer Aided Software Engineering (CASE) tools in favor of more and more complex development environments. As I work with clients around the world, I am amazed how complex their development environments are and how difficult it is to do the simplest things. In previous Advisors, I have commented on how difficult something as simple as deployment (of anything) is today.
This is a travesty! Deployment should be as easy as pushing a button. To use a tried and true object paradigm: software tool vendors ought to "hide" the complexity of deployment from the developers.
The same is true of security. I have watched development teams all over the world struggle to get their programs past operational security barriers long before they should have been worrying about fitting into role-based security or biometrics or anything like that.
Complexity is killing us and it doesn't have to. We need to reduce the high-order complexity of our systems and our programs. But we can't program our way out of complexity, we have to architect/design our way out! Recently, I read a long article on ways around the "buffer overflow problem," which continues to allow hackers to break into our operating systems. We know how to solve the problem -- make it a systems error with no return -- but there are some presumed performance problems, so we add complex, tricky code to try to get rid of a design problem and instead confound our difficulties.
Complexity doesn't scale! It's much like Michael Jackson used to say of optimization, which is the reason most often given for complex design, "Don't do it, and if you have to do it, don't do it yet!" Every generation of new hardware often erases the need for the previous generation's complex optimization schemes. But complexity, once loosed on the software world, is nearly impossible to take back, because, naturally enough, people take advantage of it.
In the end, nothing scales like elegant design. Despite nearly a generation of "denormalization" tricks, Codd's rules of normalization still yield databases that are maximally flexible and consistent to update, where denormalized databases are enormously difficult to update or extend.
Every once in a while, I end up talking about the design of things like operating systems or teleprocessing or workflow management systems design, and people go off on how hard these tools are to use and to manage. Having worked in all of these areas, I can tell you that they don't have to be so difficult or so hard to manage.
All of that is bad design -- the result of having too many coders and too few designers and architects involved. The fact that more and more people have the term "architect" in their title doesn't make them real product architects. The real architects fight complexity every day. They know that giving in to bad design makes every thing else really difficult.
-- Ken Orr, Fellow, Cutter Business Technology Council
http://www.cutter.com/consultants/kobio.html
Posted by Mike at 4:18 PM | Comments (0)