Robert on Software Development

The Joy of Coding, and Code Leadership

I love coding. I always have, and I think I always will. When I’m writing code, I’m having fun, I’m satisfying my intellectual curiosity, I’m creating something, I’m accomplishing a goal, and I’m getting instant gratification. I just love to code. The thing is, I don’t get to do much of it anymore. As often happens to developers in IT, I’ve moved from the code-producing job into the application-management job. My responsibilities moved out of the of the design/develop phase of the lifecycle and into the deployment/management phase.

You can’t keep a good coder down, so I find ways to inject my true passion into my current role. I use code to solve problems that are exposed by my job. For example, I created a Windows Workflow application to help me manage the technical review process for change requests, which are my business responsibility. Rather than have a coding role mandated by the needs of a development project, I code tools that help me—and the people I work with—get things done. It’s not any more or less noble than any other coding job; it’s just, well, different.

And because I will always be a coder at heart, I’m looking for ways to extend my knowledge of software development into my role in the PMO, and future roles that I might drop into in the future. So I’m reading a book called Code Leader by Patrick Cauldwell, which came recommended by Scott Hanselman (who wrote the foreword), and quite luckily, I won in a raffle at the Lansing Day of .NET last month. I had been looking for a book that summarized the modern responsibilities of a software development manager so it was quite fortuitous that the book dropped into my lap. It covers a variety of topics that are the hot-button issues of today, like continuous integration, test driven development, dependency management, and Model-View-Presenter. I’ve been pretty pleased with it so far. I had never really understood continuous integration until I read about it in this book. Discussions about CI always leaned toward the details of CruiseControl rather than the theory behind CI.

If I can be a strong development manager and combine that with my IT management skills, then I can achieve my goal of quality software that works. Maybe that should be capitalized. Quality Software That Works. QSTW shouldn’t be a dream. QSTW shouldn’t be a product of processes and meetings. It should just be. And the path to QSTW is established in books like Code Leader and Code Complete.

I am always looking for ways to improve my own coding and the projects under my watch. Keeping up with the changes and new technologies in the software development world is a constant challenge. But that’s a topic for another post.

Posted in Enterprise | 3 Comments »

My To Do List

Today I finally received my copy of Pro WF 3.5, which is a great book about Windows Workflow Foundation (WF) and how to fully take advantage of it. I’m very excited about WF and I see it becoming the focal point of application development in .NET shops over the next couple of years. I’ve already created a WF application for my current role (it helps me manage the change control technical review process), and I’m always improving it. I might even rewrite it as a state machine workflow.

Oh boy do I have a lot of things on my plate. Let’s see:

• Studying for my CAPM certification
• Studying for my ITIL v3 Foundation certification
• Mastering Windows Workflow so I can accurately present it
• MCSD.NET by the end of the year
• More posts on this blog

It’s good to have a lot of things to do!

I return to the office on Monday after a nice week’s vacation. I stayed at home and did some things I had been meaning to do for quite some time, like wash my car and organize my study. I know it’s not much of a vacation but it’s important to step back once in a while and manage your own personal life processes.

I have some good ideas for future posts that I will turn into reality in the coming days. I hope you check back often!

Posted in General | No Comments »

Don’t Hate the Game, Hate the Process

I’m not a big fan of the one-size-fits-all approach to processes. I think that processes can be good, like when they formalize the way people do things and establish a single point of understanding. I think that processes can be bad, like when they’re so complex and unrelenting that they get in the way of actual work.

Some people think processes are the silver bullet to every problem. “That wouldn’t have happened if a process had been in place and followed,” they say. Other people think processes are a waste across the board. “We did just fine before management started making us follow this process, and now it adds three weeks to our work,” they insist.

The big question is, how do we meet halfway? How do we show the value of business processes while not forcing people to choke them down? How do we establish guidelines for business process management and still let people do their jobs in the way they are most productive?

The Daily WTF had a recent post (albeit fictionalized) about how a blind adherence to processes completely eclipsed common sense. I can’t personally believe that the people in that story would be so ignorant as to lose an entire day’s work from such a simple matter, but at the same time, the story does have a point: IT stuff is not trusted as much as they should be, and the checks and balances in place can cause more trouble than they’re worth. That’s not the fault of “business process management.” It’s the fault of the people who put the processes in place, ensure they’re being followed, and carry out the work involved. In other words, everyone.

On the other side of the coin, there are untold numbers of success stories that involve business processes that work. We never pay attention to the things that go right; we only care about the things that go wrong. Never mind that the electricity stays on when you pay your bill, or that your car hasn’t been repossessed because the bank paid your check to your lienholder. We ignore these things because we take the processes for granted, and because they are someone else’s problem.

What do you do when the process is choking the life out of your work? You change it. I’m reminded of a story I heard in a computer science class I took a long time ago:

I worked for a shipping company for several years in the data processing department, and since I did a good job and my programs worked, I eventually got promoted to supervisor. My job duties included everything I was already doing, with some extra responsibility over the other data processing clerks.

One Monday I came into the office and my manager called me into his office. “John, we need to talk about one of your clerks, Bill. The computer says he has processed an average 24 large shipments over the past three weeks, and the minimum threshold for data throughput is 30 shipments.”

I knew he had been having some trouble at home with a sick child, so I didn’t push him to work harder. And I didn’t even know there was a “minimum threshold for data throughput.”

“We want you to let him go,” my manager said. I was shocked and tried to change his mind, but he had the hard data showing my coworker’s productivity.

A week later my manager called me into his office. “I see you didn’t let Bill go. I’m glad you didn’t because his output exceeds the minimum by a large amount. But next time, talk to me before you go against what I say.”

I couldn’t fire Bill. He wasn’t the problem. It was the program. Some programmer had made an arbitrary decision to set a default value for a variable to 30–the number of days in the month of June, when the code was written–and I changed it to ‘0′. The “minimum threshold” that my boss was talking about was the initializer for a counter that tracked all processed large shipments by a user. Since the code was testing for values less than that “threshold,” an exception was thrown. Someone had written a business process around the code, instead of the other way around.

I think the moral of his story is “common sense prevails.”

Posted in Enterprise, Process | No Comments »

The Importance of Being Ernest (in Service)

How many times have you heard the expression, “the customer is always right?” I’ve been giving this a lot of thought lately as I work very closely with my customer and make daily decisions that affect them.

On the one hand, there’s the issue of what the customer really wants and believes they need for their business. This can be driven by any number of factors, including political and financial (the two biggest). And on the other hand, there’s the issue of what level of service you can provide to the customer, most commonly impacted by financial drivers, commitments made, and the overall attitude of the customer involved.

All of that is to say that from the customer’s perspective, they’re paying for your service and should get what they want. From the provider’s perspective, there are limits as to what can be done and expectations need to be managed up front.

Unfortunately, no level of preparation can cover the odd and occasional problem. Service level agreements are fantastic for managing expectations, but when a server goes down the customer finds little comfort in the documentation outlining an agreement.

With this topic in mind, I found two very interesting blog posts today that provide different perspectives on the customer-provider relationship. The first, from Eric Lippert, is entitled “Customer Service is Not Rocket Science, Part Two.” Eric had an unfortunate experience with a bigoted lawn care provider and details his experience trying to get the middleman who set up the service to capitulate.

The other post is a reprint of an email Bill Gates sent regarding Windows usability. This is a very curious email because Bill Gates is both a provider (Microsoft) and a customer (user of Microsoft products), and as much as he’d like to, he’s not able to get involved at every stage of every product. So he’s a user just like us.

It is only with experience that we figure out how to best react to our customer’s demands.

Posted in Enterprise | No Comments »

Nobody is Good Enough for Everything

Back when the dot-com boom was going on, anyone with HTML on his resume could get a job in the tech industry. When the bubble burst, those people were naturally weeded out of the industry as they couldn’t find sustainable employment in the post-boom and post-9/11 economy.

Fast forward to eight years later, and we’re in the midst of Web 2.0. Google is the undisputed king of search, and Microsoft does a lot more than just make Office these days. The people who work for companies like Google and the cadre of Web 2.0 startups are typically highly educated and highly skilled. This is a stark contrast with the previous boom of internet companies.

The disturbing aspect of this second boom is the evaluation of potential employees, both in the measurable (advanced degrees) and immeasurable (intelligence). There is almost a clique-like mentality emerging from these companies, all of which want to hire the best. FogCreek, Google, and Xobni are just a few of the companies who go on about how they’re looking for the best and the brightest.

There’s nothing wrong with wanting smart and highly educated people to work in your company. There’s nothing wrong with spending your time and money seeking out these people. The problem is the sanctimonious attitudes of the people who work for these companies.

Let me single out Steve Yegge, whose pompous post entitled “Done, and Get Things Smart” (a riff on Joel Spolsky’s “Smart, and Gets Things Done” mantra) is so full of self-righteous wank that it’s nearly impossible to wade through the whole thing.

Steve spends 5022 words telling us how we should only hire the best (superheroes, he says).

Ok Steve, we get it. Google hires smart people. Everyone wants smart people. Nobody wants to hire an incompetent and inexperienced person to do a job that requires significant skill and innovative thinking. But listen: you’re a search engine company. You’re not NASA. You’re not working on a cure for cancer. You’re not trying to find a way to end world poverty. You’re not trying to find a way to detect catastrophic weather in east Asia.

You make a search engine. It’s a damn fine search engine, but it’s still just a piece of software. Get over yourself.

One thing I do have to concede to, however, is Steve’s citation of the Dunning-Kruger effect, which proves Darwin’s assertion (and the conventional wisdom) that the people who know the least think they know the most. This is true in every industry, every society, every community, everywhere. Does anyone truly want to admit to himself that he’s incompetent, when we’re constantly told that we’re all special in our own way?

I don’t know if the Dunning-Kruger effect applies to me. I think I’m smart, but should I not? Am I actually incompetent because I think I’m smart? Or am I actually smart because I know what I’m not good at?

At the end of the day, I just try to do the best job I can for my company and my customer, and I derive personal pleasure from that success. And that, in my humble opinion, defines competence.

Posted in Enterprise, General | No Comments »

New PC, New Risks

The subject sums up how I feel today, now that my employer has replaced my long-in-the-tooth Latitude D810 with a brand new Latitude D830. It may not sound like much, but it’s a massive upgrade. Now I can run Visual Studio 2008 and Microsoft Outlook at the same time!

The laptop was delivered to me pretty bare, with just the standard install (Windows XP and Office 2003). I knew I wouldn’t have time to get it set up tomorrow in the office, and besides, it wouldn’t be fair to bill my customer for my time spent setting up my own machine, so I brought it it home and got it all ready for work tomorrow.

After I finished installing everything, setting my desktop background, and organizing my folders, I leaned back in my chair with a smug sense of accomplishment. Then it hit me: I have a meeting tomorrow morning at 8:30, and I’ll need to use my PC in the meeting to draw network diagrams. I don’t have any of the supporting documentation for the meeting on this new laptop. I got so caught up in the excitement of replacing my old one that I neglected to think about the risk of trading it in on the new one the night before a big meeting.

This is the kind of risk I point out on a weekly basis in my role in the PMO. People want to make changes to production systems and they think the changes are minor and easy, so they don’t want to go through the formal process we have in place. But the smallest change can quickly snowball into the biggest problem. One little oversight can cause a massive headache. And that’s where I am now.

I’ll be ok in the meeting tomorrow because I’ll go in earlier to get the files onto my machine. That means I have to get up earlier, and have a more stressful morning. That bit of unpleasantness could have been mitigated by simply waiting a day. I’m mitigating my risk by sacrificing some sleep.

Since I’m not a morning person, getting less sleep risks a tired afternoon, and my technical review board meeting is tomorrow afternoon.

Do you see where this is going?

Posted in Enterprise, Process | No Comments »

Thoughts on certifications

Over the past fifteen years that I’ve been in information technology, I’ve heard countless different opinions on the value of certifications, which certifications to get, the role of certifications in hiring and promotion decisions, the degree vs. certification argument, and whether certifications lead to vendor lock-in.

In my younger days (around the late 1990s), I really wanted my Microsoft Certified Solutions Developer certification. I couldn’t afford the classroom instruction, so I studied for the exams via books. I never got the MCSD because I never had the time to seriously devote to it: I was too busy actually writing code. Meanwhile, people I worked with were sent to “Visual Basic training” and walked out with their MCSD certifications, having never written a single line of code for a project.

As you can imagine, that left me quite disillusioned, so I never really put the time into certification after that. Eventually, my years of experience and my commitment to my employer eclipsed the value of certification. I never cared about Netware certs, or A+ certs, or Cisco certs, or Citrix certs, as I didn’t need any of them. I worked in the Microsoft world, after all.

But now I’m in a position where a different kind of certification is important. Rather than attest to my technical skill or my knowledge of a vendor’s product, these certifications indicate my deep understanding of a standard body of knowledge. Project Management Professional (based on the ANSI standard PMBOK), ITILv3 Foundation, and Certified Information Systems Security Professional (ANSI accredited) are just a few of the certifications that are becoming more prevalent across all IT domains. I’m even starting to see people outside of the PMO, such as software developers and technical writers, work on PMP certification. These certifications aren’t used to measure skill. They’re used to indicate a level of understanding about a generally accepted set of practices.

This represents to me a shift to valuing the importance of a broader view of IT and the concepts we employ, rather than just technical aptitude about a vendor’s products.

Posted in Enterprise | No Comments »

Process modeling, or modeling processes

Lately I’ve been working on documenting the processes I use for reviewing change requests. There are two processes that are used for this weekly endeavor. One involves the lifecycle of a change request from creation to technical approval (my job), and then it goes off to higher powers. The other is the process I use in the actual technical review.

I can represent the high level process rather simply.

Of course, there’s a lot of stuff going on in there, but it works at a high level. The detailed process is much more complex, and I don’t have a model for it yet because I haven’t figured out how to represent it in notation.

That describes, then, a larger problem: is my process so complex that it is too difficult to model? Or is the process flawed and should be redefined using a model-driven approach? The current method is a very manual process. My attempts to automate individual aspects of the process have proven quite difficult. That indicates to me that the overall process is flawed and needs to be redesigned.

I think I’m going to take a step back and analyze the technical review process with a more objective eye. That is, instead of looking at it in terms of "this is what we’re using, and it gets the job done," I’ll look at it as "this is a new process that has not been executed before." At the end of the day, the process should be easily understood by people who are not intimately involved with the actual work.

Perhaps at that point, the process will be clearly documented and individual tasks can be relegated to automated workflows. More on that later!

Posted in Modeling, Process | 2 Comments »

Effective communication tools

I’ll admit it: I was a bit late to the Twitter game. I remember when it launched, but I honestly couldn’t find a value for it beyond the novelty. Over the past year, Twitter has become very popular with all kinds of people, evolving into a communications medium through which entire conversations about all kinds of topics occur. I decided to give Twitter a second look.

I was quickly overwhelmed by the sheer volume of Twitter posts, or tweets, from the people I was following. I eventually had to pare down the list of people I followed to a select few, just so I’d be able to keep up. With all the things I’m working on, I don’t really have the time to read 500 tweets per day.

Yesterday I came across a blog post from Rick Strahl entitled Twitter this, Twitter that. Around the same time, I was thinking of a post for this blog about how to manage communications across large and disparate teams. The confluence of my plans, his post, and my own Twitter experience was too perfect.

In my current role, I’m in charge of the technical review board, which means every change request comes across my desk for technical evaluation and approval. In the process of dealing with these requests, I work with the change builder, the other folks in the PMO, my customer, and my customer’s customer. That’s a lot of communication on a daily basis. Fortunately I have a workflow in place for the technical review board meeting (that’s a future post), but the communications with stakeholders and change builders is not built into that workflow. I have to manage it all myself, including phone calls and emails.

A tool like Twitter, deployed within the enterprise and properly used and managed, would simplify this type of communication and fit nicely into a workflow. Imagine a Twitter feed that contained updates about the lifecycle of a change request, or specific activities in a workflow, or status of a meeting as it occurs. Long emails that get lost in the shuffle would be traded in for 160 character posts that get the information across very succinctly.

There is a plethora of enterprise communications tools, like Groove, SharePoint, Office Communications Server, and so on, but they are all large installations with a lot of overhead. Twitter is lean, easy to use, fast, and fun. These are factors in Twitter’s success. In fact, the sheer success of Web 2.0 as a whole is partly hinged on the simplicity of the tools involved (compare Google.com to Yahoo.com). And gaining adoption of a tool like Twitter in the enterprise would depend on these factors as well: how much of an impact it will have out of the box.

The larger question is, how do you get Twitter functionality in the enterprise without using the public service? Well, the point isn’t using Twitter itself, but rather gaining the rapid communications that the service provides. That will be up to the software vendors.

We’ll see how this plays out over the next six to nine months.

Posted in Enterprise | No Comments »

Extending quality across all domains

I have a genetic disorder called Crouzon Syndrome. This disorder causes certain facial deformities that are corrected via reconstructive surgery. From 1991 to 1993, I underwent these surgeries. One of them, performed in 1992, involved correcting my orbital hypertelorism. Without getting too deep into the gory details, I will say that it involved inserting a needle in one tear duct and pulling it out of the tear duct on the opposite eye.

What does this have to do with IT, you ask? Bear with me.

During that eye surgery, I woke up. I was completely aware of what was going on: I could hear the surgeons talking, I could feel the needle in my eye, I could hear the equipment monitoring my vitals. I couldn’t move (due to the muscle relaxant), and I couldn’t talk. I was trapped in a waking nightmare, and it is one of the most devastating experiences of my life. I don’t know how long I was awake, but I knew that if it lasted much longer, I would surely die. I said a silent prayer in my mind and then fell back asleep. I was sixteen years old at the time.

When I woke up in the recovery room later, I was screaming. All I could do was curl up into the fetal position and cry out for my mom. The nurse tried to calm me down, and I said, "I woke up during surgery!" At that moment, all hell broke loose in the recovery room and suddenly I was surrounded by many doctors and hospital staff.

I was finally able to calm down when my mom came into the recovery room and the doctors undoubtedly injected me with a sedative. Once all the fracas had subsided and I was wheeled out, my anesthesiologist approached me. I couldn’t see him, as my eyes were bandaged, but I could hear him. His voice wavered as he expressed how sorry he was, and then he broke down into a sobbing apology. I told him it was ok, that I forgave him, and then my dad drove me home.

Statistics vary on how many people wake up during surgical procedures, but the number hovers around 1 in 1000. Those are pretty bad odds for those of us going under the knife. There is a plethora of different reasons for surgical wake-ups, including heart conditions, unusual brain activity, nicotine, and, in my case, a bad judgment call on the part of the anesthesiologist.

And there’s the correlation to enterprise IT. The physician, who had years of education and experience, professional certifications, and professional licenses, made a mistake. He’s human. He assessed a situation, made a decision, and it didn’t work out.

Likewise, IT workers draw upon years of experience and education, plus industry certifications, to ensure quality software and systems. And just like my anesthesiologist, we make mistakes that all of that experience and education can’t prevent.

How we react to those mistakes defines the strength of our IT infrastructure. There are countless processes and paradigms that can help your organization manage risk and react to it. You can go rigid with CMMi, be loose with agile, or somewhere in between. The system works, as long as your processes are well-documented and understood by the people involved in the decisions.

Quality is a universal concept. Build it in and things won’t go wrong. Add it on and you’ll be able to react. And if you do make a mistake, accept responsibility for it so everyone can move on. At the end of the day, the last thing we want is the customer to wake up screaming about his system being offline.

Posted in Enterprise | No Comments »