Robert on Software Development

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.

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!

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.”