Dashing through the snow
To cubicle hell we go
Whining all the way
My coffee’s getting cold

My boss is always late
To the meetings she sets up
I want to leave to do my job
But everybody waits

Oh…

Jingle bells, snotgun shells,
Coming from my nose
Winter’s here, and as I feared,
I’ve got a real bad cold.

Jingle bells, snotgun shells
Spraying on your clothes
Now you’ll get sick, unless I’m thick
Cuz I won’t work from home!

Yup. I’m glad that’s not me anymore. Neener neener neener. Someone who knows me is going to read this and point out that I don’t drink coffee. It’s just literary license.

Merry Christmas.

Most advice regarding office romance will tell you to be discreet, steer clear of your managers and subordinates and review the HR policies. That advice assumes you are going to stay with a company and can successfully navigate the political hailstorm you will fall into. The better advice – advice that is both easy and foolproof – is just don’t do it.

Don’t do it. You will want to, but don’t. What about that really cute girl who flirts with me? Don’t. What if I really dig the guy in accounting? Don’t. What about my manager who says he can “take me far”? Really don’t.

Below is a handy chart for when to pursue your office romance

The fact is office romance is prevalent. So is surfing for porn at work. The best advice early on is to avoid both. You may find a date, but you’re not likely to find your soul mate. In the mean time, you will have to deal with increased HR scrutiny, jealous coworkers, office rumors, productivity losses, suspicion of favoritism, potential career damage, loss of power and the threat of sexual harassment lawsuits. And that’s only if you’re dating.

DJ1.0 is a contributing editor of TechDarkSide.com. We don’t know much about DJ1.0, since he participates in the dark side anonymously. You can reach DJ1.0 at dj10@techdarkside.com.

This post was originally published on TechDarkSide.com on February 27, 2007. As one of the most popular TDS posts ever, I thought it was about time to run it again.

~Dave

In my previous post, I described the natural tendencies for people to dismiss as “useless” certain skills and knowledge. By extension, the people who use or have those skills are treated as “useless”. This in turns leads to conflict and sub-optimal teams that are not utilizing the hidden and unique skills of each member.

After reading this, someone said to me, “Well that post was useless.” You may agree. Of course, missing the irony of that statement is precisely the point of this post.

Usefulness is an assessment of a certain kind of value, namely utility. Utility depends on context, audience, and any number of other situational factors. All things are not equally useful, nor is the same thing useful the same way all the time. It is not always obvious but we need to avoid this kind of thinking. It is better to have a culture where value evolves from context instead of being dictated a prior. (Speaking Latin is definitely NOT useless. )

Here are some examples of skills, knowledge and attributes that are often overlooked, under-utilized and often punished.
Legacy Knowledge
Far from being useless, legacy knowledge about older systems, cultures, events, processes are more important now than ever before. These things grew up without the kind of documentation and traceability we have today. Sometimes all knowledge about these things only exists in people memories. Sometimes it is accidental; sometimes it is planned. However, that knowledge is extremely valuable, especially when it comes time to retire such a system.

This knowledge extends beyond understanding the technology of some crazy legacy system. Knowing the history of a system, or the back story on the culture or group that created it is valuable. Knowing the processes that exist and why some work-around became accepted is extremely important. If you don’t know where you have been, it is hard to know where you are going. People in IT ignore that at their peril.

Connaturality
This is about the natural connection between things. Mainframe programmers must get tired on enduring the remarks of their mid-range counterparts. They are constantly hearing about how the mainframe is dead. It is not dead; it is not dying. Not even close. Leaving that aside, how many people would think to involve their mainframe gurus in their SOA efforts. (Crickets chirping. Long awkward pause.) Exactly my point.

Connaturally is about the natural connection between two things. It is different than context which is discussed in my next post. The mainframe is – at its core – a shared computing resource. Mainframe departments are far from the dinosaurs others think they are. Mainframe groups have decades of experience with things like dynamic provisioning, large scale development, security and metering which most SOA groups are just now struggling with.

If you want a group with experience in real-world large-scale shared data environments, you go to the mainframe folks. Here is an entire group whose core structure, knowledge base and culture is built around managing, developing, testing, servicing and protecting a shared resource used by an entire company. Would not some of that experience naturally connect with SOA? Of course it would! It is a natural fit as long as someone doesn’t dismiss batch COBOL as useless.

In my final post on this, I will visit a few more items that we in IT tend to ignore.

Some people say I have a lot of skills. I prefer the term “mad skillz” – with a ‘z’ not an ‘s’ (or should I say with a 0x7A, not an 0×73.) Some people add the adjective “useless” before the skills part as a kind of modifier / insult. They could not be more wrong.

Let it be know, that if aliens invade Earth and the only way to defeat them is by writing a virus in Forth, then I’m your guy. If they can be chased away by reciting all the words to every Run DMC song, then I would be proud to serve. If, on the other hand, they can be scared away only by someone starting a fire with only two sticks, then we are all doomed.

You see, I’ve never had to start a fire – at least not with sticks. But, if by fire you mean pressing start on a microwave, then I am practically Charlene McGee. (Esoteric references that only make sense to six people is another “useless” skill of mine) Nor can I grow food. I rely on the skilled farmers who work at Krogers. These farmers can grow 2 ounces of cookies wrapped in three and half pounds of plastic. Now that’s a skill.

If the Russians invaded my high school and I was forced to fight hand-to-hand along side the Wolverines, the Russians would pretty safe – unless the Russians were dressed as ducks and I had a light-emitting gun from Nintendo. If the Russians were falling from the sky leaving trails of color and all I had was a trackball and a red button, I could protect us. Other than that my skills would be “useless”
The other time “useless” is used is when it refers to knowledge. People often lament the “useless” trivia that pollutes their head. For some reason, I still know the square root of 8 to the 11th place. (2.82842712475) and every movie Gary Coleman has ever been in. (There are eight, including the tour de force titled “On the Right Track.”) As much as I would like to garbage collect this information, doing so would be a mistake.

I bring all this all up to hopefully trigger what is a normal human reaction. The normal reaction is to simply reject the value in any of this stuff. It is normal to simply discount some skills and knowledge as useless and then (in some tiny way) also discount the person.

The point is not that every skill is valuable all the time. The obvious point is that we tend to quickly discount and dismiss other people’s contributions if they don’t look like ours. Not to sound preachy, but when you don’t care about someone – they can usually tell. Humans are highly sensitive to this kind of thing. We have more facial muscles than any other animal for a reason. Because we have evolved to pick up tiny subtle signals that you aren’t even aware you’re sending. More importantly, looking passed someone’s potential contribution is an almost guaranteed way to miss out and underdeliver.

Good thing Beethoven’s mom didn’t tell him to stop making all that racket and go out and play with the other kids. Lance Armstrong rode a bike and later becomes a beacon of hope for cancer survivors and funding windfall for research. Bobby Fischer played a board game and became a symbol of American creativity, passion and strength against Russia during the Cold War.

There are many ways in which our skills can be used beyond the obvious. There are many skills that we discount everyday taht could – if utitlized – greatly improve our delivery. Appreciating these can go a long way towards building a more robust, creative and agile team. In my next post, I will describe some of these and discuss how we can incorporate them into IT.

In my last two posts, I have been asserting (successfully?) that the rigor enforced in academic research and engineering disciplines could rescue IT from some of its self-destruction behavior. So far, I have received many dissenting comments from people in just about every section of IT, data warehousing, database, usability, marketing, management, and infrastructure.

The comments are all the same. “Our data is not ambiguous. We have lots of defined measurements. We are rigorous and we do know what our data means.” That is precisely my point. YOU have YOUR measurements. YOU know what YOUR data means but does anyone else? The knowledge your group has internalized doesn’t help generalized understanding.
For example, consider an extremely valuable group like infrastructure. Infrastructure monitors availability to 1/10 of 1% increments, every 15 seconds, with very precise graphs and charts and massive amounts of data and historical trends. That rigorous, right?

I’m not arguing for more data. I’m arguing for more meaning.
So I asked what availability means. What is 95% availability? Well as it turned out it didn’t include weekly scheduled maintenance outages. It didn’t measure when an application module was faulty but the application still ran. It didn’t measure when users were blocked from logging in due to a firewall issues. This is NOT to say they were wrong, they weren’t. But decisions are being made based on data that people don’t understand. If I tell my wife, “I’m 100% faithful.” She is not expecting me to leave out weekly maintenance windows.

Getting back to availability, because the horse might still be alive, what good is 95% availability? Quick back-of-the-napkin calculations tell me that there are 21 hours a week between 1:00 and 3:00 AM. Are you really doing business during that time? Sure in this global 24×7 economy, it sounds good, but does it make business sense? Are there too many opportunity costs in keeping a system up when you don’t need to? Who knows, but without real meaning in your data, you really can’t ask the question.

I’m not arguing for more data. I’m arguing for more meaning.

The great irony of IT is that even as we live and breathe in massive seas of data, we simply don’t understand data itself. We have 50 million rows of transaction data and we don’t know a thing about our customers.

One of the things that I would encourage IT to borrow from academia is peer review. In academic culture there is openness to sharing and review. In fact, without peer review, your research goes nowhere.

In IT the opposite is often true. The more people that know about what you are doing, the less likely it will succeed. Academia expects you to publicly publish your works, expand on other studies and subject your research to rigorous peer review. It also has an entire culture built around that premise. IT has a real aversion to this kind of thing.

Thankfully this is changing. The emergence of wikis and agile ideas are starting to move IT in the right direction. However, without a cultural shift, it is bound to have problems. Having a wiki doesn’t make it any safer for your employees to express new ideas and it doesn’t make teams collaborate or share. But having the tools around to support a cultural change can make all the difference.

At first blush, this may seem widely off-topic. I promise it is not. The core of these blogs is about helping IT make better decisions. Some focus on empowerment and training of people. Others, like me, believe a cultural effect is the solution. Others tend to gravitate towards process improvement. Then there are some –probably masochists – want to change all three. What I observed yesterday at my garage sale provides some common anti-patterns that often plague IT decisions.

A quick tangent: Because of how I grew up, I don’t like used things. I don’t like the uncertainty of used items. I don’t like the idea of taking other people’s stuff. I don’t even like used cars, let alone socks. In my long career of conducting two garages sales, I am wholly overmatched by what I can only imagine are CIA trained garage sale ninjas. These people are pros. They stick and move. They travel in packs. After the siege, I have an empty garage and only $1.37 in nickels to show for it. I’ll be ready next time

Value is as value does

Value has a ceiling it never reaches and a floor it sinks right through

I don’t know what it more depressing, buying a $600 diamond encrusted HAM radio or selling it for $10. Like most things in life, when I make purchases, I have great plans in store. I sell these great ideas to my wife and CFO who approves the budget. I even convince myself. Invariably, I don’t get near as much value or use as I thought I would. This is especially true in IT. Refactoring may be both needed and necessary, but will almost never return your investment – especially not as much as promised. Most of the time, it is a red queen problem. We are not trying to stay ahead; we are trying to stay afloat.
Conversely, the value of your IT initiatives depreciate almost the day you deliver to production. Business and technology change to fast. The system you thought would give you at least ten years before replacement, looks soggy (a new phrase I’m trying to introduce) within two years. My $600 turned into $10 is less than three months.

Never count your money while you sitting at the table

Ok, I didn’t write line – nor did I invent delicious slow roasted chicken – but Kenny Rogers was on to something. Never count the money in the pot – it’s gone. When surveyed, people seem to understand this concept. In practice however, as Las Vegas will attest, people don’t act that way. A bad bet doesn’t get better odds just because you put money in. (And don’t be difficult and bring up “pot-odds”). Similarly a bad project doesn’t get any better just because you already spent millions. In fact, it gets worse.

I kept thinking about all the money I spent on my diamond crusted combination garlic press / DVD burner. It would be silly to sell it for $5; I spent so much on it already. But, that money is already gone. It is counter-productive to keep holding on because of that. Plus, if I pass on the offer, I’ve lost another $5.

When opportunity costs knock

After three humiliating hours of having total strangers manhandled, undervalue, insult and demean my possessions, I have almost $6 to show for it. For those who didn’t buy my diamond encrusted graphing calculator, that’s only $2 / hour. Some would consider that low.

There is such a thing as lost opportunity. (My wife for instance had the opportunity to NOT marry me. She didn’t take that opportunity and now she is stuck with me. Sucker.) While conducting my garage sale, I was unable to do other things of value. I could have been writing or painting or finding something else to encrust with diamonds. Therefore, I was losing my time and the opportunity to invest time somewhere else. In return, I was getting paid $2 / hour. It wasn’t worth it.

This is a very familiar business concept, but poorly practiced in IT. Opportunity costs are a killer. Every time you fix a defect in production, because you “saved” time in testing, you are actually costing yourself time. (You are actually costing yourself more time because of the nature of the fix required.) Now while your developers are busy fixing this defect, they are not having the opportunity to write new enhancements or improve testing. This creates a time crunch, which in turn leads to counter-productive time saving measures. These measures, of course, drive up defect rates. To keep the analogy, we lost $10 worth of productivity, paid $2 for it and think we saved $8.

After the delivery matters

Well that’s my garage sale for this year. I can’t wait for next year when I can punch myself in the face again. You know what they say, “If at first you don’t succeed, then your odds of failing again are actually higher the next time.”

In my last post, I made some assertions regarding the benefits of rigor. Now let me define what that means and how to apply it to IT.

What rigor does not mean is the normal IT approach of obstacle based development. Rigor is not about a series of flaming stage gates, approvals, and forms. Rigor is not constraining what people do and when they do it. Rigor is about empirical evidence and making decisions based on what is commonly referred to as data and sometimes even facts.

Here are two important examples.

1) Do not state the obvious. Only interesting conclusions are interesting.

As I prepared my thesis proposal, I was constantly reminded that research should contribute to the body of knowledge. More importantly, it should expand the body of knowledge. This is why you don’t see a lot of studies about if a Porsche Boxster can outrun a stock Dodge Neon (it can) or if tabouli tastes good (it doesn’t) Masters of the obvious have trouble surviving in academia. Thank goodness.

Yet how many times have you seen IT presentations or IT vision docs that say obvious stuff like “We need to reduce expenses.” “We need to build reusable components.” “We need to enable the business.” This just in – plants need water – film at eleven. IT would be better off if everyone worked to expand the body of knowledge not parrot it.

2) Define what you mean.

This is an idea so engrained in research that it is almost second nature. In IT, it is almost unnatural to do it at all. What does “reusable” mean? What does “user” mean? What does “response time” mean? Most IT definitions are like the Supreme Court definition of obscenity – “I know it when I see it.” Unfortunately, this approach can lead to poor decisions.

The fact is that terms are not obvious. Even something as simple as “user” is ambiguous. Is a user anyone that uses your system? So a person who uses your system everyday to run their business is the same as a temp who logs in once to print-out something? Is anyone who has ever used your system a user? Someone who used it three years ago is still considered a user? What about one year ago? What about “power user”? Is this idea based on time or fluency? The fact is, how you conceptualize “user” effects how you create and maintain a system for them.

There was an old trick I used when I taught classes. I would ask the class, “What is the fastest car?” Invariably, males in the class would shout out small, fast sports cars. I would then ask, “What about for moving 8 people?” With this new context, the sports car no longer applies. This lesson was normally about requirements. (An upcoming post entitled “No one buys a drill” addresses this further) But it is also about definition. No one ever bothered to simply ask, “What do you mean by ‘fast’?”

Terms aren’t obvious in language and when you try to measure them – a process called operationalization – it gets even worse. Rigor dictates that you try to boil down your terms into something you can measure objectively. Something not only you know when you see it – but others do also.

This is normally where the “CS is an art” crowd starts to get riled up. Software architects – of which I am one – often consider what they do an art, not a science. After decades of experience, we know a reusable component when we see it. Our judgment in these matters is very good and we trust our gut. To try and operationalize that into some rigorous formula undercuts what we (as architects) do.

That premise has the distinct disadvantage of being wrong. I think the thousands of art professors, instructors of music theory, and English Lit teachers would agree with me. Art not only can be taught, in most cases, it must be taught. Mozart – despite revisionist movie history, worked extremely hard, practiced and reworked draft after draft. Bobby Fischer studied tirelessly.

Experience allows you to internalize operations you have used over and over again. Judgments made from experience are still data-based. You don’t just randomly say, “Yeah this code looks secure.” Behind the scenes, you are using objective measures and patterns. Because you are experienced, you happen to know about them. But because you are experienced, you also happen to have forgotten what they are – like a locker combination that your fingers remember but your mind doesn’t.

The important difference is that research requires you to be explicit, IT doesn’t. IT makes so many bad decisions in the name of an idea like: agility, reuse, standards. Academics may ask pie-in-the-sky questions, but they do not let ambiguous undefined terms run amok and guide decisions.

In my next post in this series, I will cover two more really important ideas that IT could use to better itself.

For most of my career, I have always been told that academia was an ivory tower. Everyone had their head in the clouds and was completely removed from the realities of day to day life. The business world, I was told, live and die day to day by real decisions made real people in the real world. Academics focus on ideas in a pretend world, businesses focus on delivery in the real one. Having worked and researched in both environments for a long time, I think most have it backwards.

I can’t tell you how many times in the “business world” I have heard (and sometimes used) a phrase like “We need to synergize our core competencies by providing an flexible abstraction layer of reusable components and agile business processes. “ I can’t tell you how many hundreds of Visio diagrams I have seen in corporate America with a magic fantasy pipe which goes into a magic fantasy application neither of which exists. In fact, I know of example after example of real businesses making real decisions based on gut feelings, personal egos, desires of what a fantasy world should look like and pure stupidly.

To be sure, academia has all of these traits. They also have a culture and system of empiricism to counter-balance these otherwise inevitable side effects when people deal with data. I can personally attest that during my thesis research, I had to use an entirely new level of rigor. If more corporations used data as rigorously as academia, better and less disconnected business decisions would be made.

There are some who say that software engineering IS a rigorous data-driven science. Software engineers like to use that phrase because it implies a level of discipline similar to engineering. I disagree. As a former double E, I can attest that almost nothing done day to day in software development remotely approaches the level of rigor required of formal engineering.

This might insult some CS people. It shouldn’t and it is not meant to. I also have a CS degree. Anyone who has read Knuth knows there is a lot of science involved. But software development, ESPECIALLY the way it is done in corporate IT, bears little resemblance to engineering.

When was the last time a programmer was sued because his accidental software error caused a crash? In fact, if you read most EULAs, you are explicitly releasing the software company from any and all liability. The EULA for XP says, “Except for a refund…YOU ARE NOT ENTITLED TO ANY DAMAGES.” It further says, “THERE IS NO WARRENTY OR CONDITION OF ANY KIND.” Try that in engineering. “Look, I finished building your house, but if it caves in and smashes your family into tiny bits, don’t come crying to me.”

What I am proposing is a return to a certain level of rigor common in other disciplines that is often abandoned in corporate IT.

In my next post, I will present some specific examples of rigor extracted from my experience in engineering and academic research that could greatly benefit business in the real world.

I’m not sure how long this has been out there but I thought I would pass it on. For those who like technology or business or how the ancient societies of Mesopotamia raised falcons – and who doesn’t – I found this: http://www.apple.com/education/itunesu/

It is called iTunes university.

Now normally I am very suspicious of any intuition of higher learning named after an appliance (I sank enough money into Septic Tank College not to make that mistake twice) but Steve Jobs personally assured my it was legit. The idea is to distribute content from universities across the country, including lectures, performances, and symposiums, through iTunes basically free. (As in free-food, not free-dom) Some are audio, though there is video also.

The content is distributed under a Creative Commons license which means you can pretend it is your own. (Not really) Now I love learning and the ability to take “classes” at MIT or Stanford sounds very appealing to me. Plus now I’m not lying when I tell people I go to MIT.

Right now, I’m listening to a lecture on Asymptotic notation, recurrences and substitution. (What is that you ask? If you have to ask you ain’t cool. Only cool kids know asymptotic notation.)

Check it out…

A journey of 1000 miles begins with 1 step – but won’t end until 1000 miles later (that’s the part they never tell you)

Since Dave is taking some much-needed time to focus on other writing, he asked me to fill in for him as a guest blogger. Extra work, public exposure, lots of spam, for no money – I couldn’t say yes fast enough. Whenever someone asks me to fill in for them – I basically respond in the same way as if they asked me to watch their children.

1. “Will there be any poop involved?”
2. “What do you want me to do when they start to hate me?”
3. “Promise me you won’t be mad if I break anything. “

Perhaps this is why I don’t get ask to baby-sit a lot….that and small children can smell fear.

Dave didn’t leave me with many ground rules other than to use my best judgment. I’m sure he will regret that. But for the time being, I am going to try and behave.

To carry forward the techdarkside tradition, I will try and focus on a lot of the same things Dave did. However, I care more a little more about the technical side of things – so don’t be surprised if I throw some big O notation in the conversation. (See, if this wasn’t someone else’s blog – I might have made a joke there.)

So this is the part where I introduce myself. I have written a few other posts under DJ 1.0. That’s actually my real name – middle school was very painful for me. Suffice to say that I have had 15 years of experience in management consulting, Fortune 100, start-up and academia. I have learned a lot – mostly the hard way – in that time.

Well, that’s it for the introductions. If there are no questions, place your tray table and seat in their upright and locked positions. An attendant will come by to collect any last minute items you may have. When we reach cruising altitude, I’ll turn off the fasten seat belt light at which time you are free to move about the cabin….