Information Technology Dark Side

There’s a soul check room when you join IT management - I turned mine in about four years ago. I kept the ticket in my top dresser drawer for a long time, just in case I ever needed the thing again. The other day I checked for it and couldn’t find it. Then I remembered - it must have been lost when we got new furniture. Flippin’ golden handcuffs.

For a few years, I was able to hold onto a little piece of my soul by blogging and writing articles, but lately I’ve fallen behind even on that, and I’m afraid my soul is completely gone. I may never see it again.

I’ve been coding lately, and that’s been a relief. Sure, it’s not incredibly complex stuff - just RSpec tests. But… still, it’s been oddly invigorating. It reminds of the time, not so long ago, when I was an expert at something. When I could code circles around myself, like the time I wrote an XML marshaller/unmarshaller for an obscure OO language, or when I wrote pattern smoothing algorithms for the high-speed cutting of carbon fiber helicopter parts.

Those were the good ole days. Why’d I ever stop doing that? What made me think management would be more fulfilling?

Java. That’s what it was. I don’t like that language. It’s a nice idea - OO with cross-platform portability, but it’s too wordy. It’s perfect for the quadruple abstraction factory guys, but not for me. I don’t want to have to instantiate four different classes just to read a file. No thank you. I prefer to just open the dang thing. Besides, that whole portability thing didn’t really work out in the end, and it never seemed to matter either. And the frameworks, with all that dang XML. Aargh. I just never liked that girl, I just liked the idea of that girl.

For a while there it seemed Java was going to take over the world. It certainly seemed to take the wind out of the proprietary language I was such an expert at. And the prospect of learning Java made me cringe.

So I turned my back on the code, and checked my soul in at my local chapter of PMI.

But that didn’t help either. The bad taste in my mouth is different now, but it still makes me want to double up on Altoids. Few things have made me want to take up drinking more than IT management.

Then along came Ruby. Well, actually she’d been around for a while, I just hadn’t noticed her. Then one day, in the middle of a ginormous crisis, I needed someone to parse a log file as big as our crisis and turn some specific time stamps into a graph. Mike Kelly did it in about five minutes. I couldn’t believe it. When I asked him how, he said “Ruby”. I didn’t start picking up on her right away, but it registered. Ruby was cute, or at least practical.

A year went by and I needed to parse some log files again. I remembered Mike and his cute little friend Ruby, and I googled her. Ten minutes later, I was looking at the graph I needed. I wasn’t quite as impressed with Mike’s ginormous crisis magic trick now, because it was pretty easy with Ruby. Java had made me expect everything to be hard.

Things blossomed from there. I discovered Rails, and I started getting more serious. Then I found some paying work on the side and suddenly critical mass materilized. Now there was money involved.

At any rate, I’m really digging this Ruby on Rails thing. I know I’m not good enough at it yet to say I have my soul back, but I’m getting there. Thanks Ruby.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Is software development a science?
I was required, as a Mechanical Engineering major, to take a C class on solving math problems with software. We didn’t talk about design patterns, or interfaces, or even clean code. We talked about theories of convergence and divergence, of Newton-Raphson, and progressively better guessing. Our work was judged based on its efficiency and accuracy at solving an equation. That was science. And math. It was also one of the reasons why I didn’t study computer science back then - I saw CS as just that. Using programming to solve progressively harder math problems, and of the science behind complex algorithms.

Software development, in the average sense, is far removed from that C class I had in college. In the last eleven years, I have only written software to solve a mathematical problem once, and that was related to smoothing a curve so that a machine could cut it more smoothly. The rest of the software development I’ve been involved may have been programmatically complex, but it was always scientifically simple. There’s nothing all that scientific about determining whether an unemployed mentally ill person qualifies for state benefits or integrating a back-office billing system with an IVR system to calculate how many minutes are left in your cell phone plan.

I don’t really think of software development goodness as being grounded in provable scientific principles. You can’t test a software application the way you would test a scientific postulate or mathematical theorem and decide that one application is “true” (and proven) while another is not. If you asked 100 different rocket scientists what the fundamental scientific laws were behind calculating the thrust of a rocket engine, invariably the three laws of thermodynamics would come up. But ask 100 software developers what the fundamental principles of software development are and you’ll get 85 different answers.

This may in fact be due to the relatively low barriers of entry into the software development field (as compared to the rocket scientist field), which results in a far lower formal education requirement than rocket science. Take me, for example. I was a rocket scientist who became a software developer, with nothing more than a fortran for babies class to go with the C class I already mentioned. Now try to go the other way and make a computer science graduate a rocket scientist. It’s possible, but not common or easy. Combine that with better pay in 1997 for software developers than rocket scientists and you’ve got a flood. Anyway, the point of this digression is that there may be scientific principles out there that “real” computer scientists know but hacks like me don’t. I concede that.

Does that make it art?
But… does the fact that software development isn’t really “science” per se make it art? I sometimes find myself feeling that way, particularly when I see a young software developer who instinctively writes good, clean code and then compare him to a crufty code factory with 30 years of experience. But I’m not sure. How would I know if software development was an art? What are the rules, and why does it matter?

If software development is an art, then the importance of sheer talent increases dramatically. That appeals to me. But the importance of form over function would also seem to rise, which doesn’t really sync with me. How many times have you bought software JUST because it was beautiful? Or because it matched the colors in your bedroom? Granted, I won’t use Open Office because I think it’s ugly, but I also won’t use Apple Pages (which is quite attractive) for complex documents because it doesn’t give me what I need.

At the workshop on technical debt that I attended recently, a few people proposed that software development was a craft. So I looked up craft in Webster and here is what I found: an occupation or trade requiring manual dexterity or artistic skill. Hmm. Well, typing requires manual dexterity, but I don’t think that is enough to make SD a craft. The notion of requiring artistic ability appeals to me though.

Is artistic skill required to make good software?

I don’t think so, at least not on average software development projects. I think we routinely make good software with average, not-particularly-artistic developers all the time. So why does this notion appeal to me?

I think it’s because good software development has always seemed very difficult to teach and because there are so many different opinions on what makes software “good”. It’s almost as if, kind of like art, I can’t tell you exactly what I like about “good” code, but I certainly know it when I see it.

That was before the Workshop on Technical Debt. Chet Hendrickson and Ron Jefferies shared something there with us that I found to be very eye-opening. The attributed it to Kent Beck, and it immediately stuck for me.

Four rules of simplicity in software
Good software will do the following, giving preference to the earlier rule when there are conflicts between them:
1) All tests run successfully
2) There is no duplication
3) It expresses all ideas relevant to the problem
4) It minimizes all architectural artifacts

This article isn’t about these rules, but my sudden awareness of them made me re-think my opinion about whether SD was science. Are these fundamental “laws” of software development? Certainly not in the sense of being provable. But they are logical and they clearly work in terms of following them will help create clean, maintainable code.

I could go on about art, science, and craft for thousands of words, but I’ll spare you. Let’s just jump to my conclusion of the day. It may be different tomorrow, but here is where I stand at the moment.

Software Development is Best Thought of as a Medieval Trade
In medieval times, tradespeople learned how to perform their profession from other tradespeople in a fairly well organized guild system. They progressed through various levels of their trade in different ways, but it generally worked something like this:
Acolyte -> Apprentice -> Journeyman -> Master -> Grand Master

Tradesman with a natural talent (the artistic ability we mentioned earlier) progressed more quickly than those without, but even the un-gifted could participate in the trade as long as they could attain competence. Not everyone had what it took to become a Master or Grand Master, but those with special gifts of talent and the luck to live long lives could attain those levels.

Journeyman tradespeople had responsibilities to teach the apprentices the principles of their trade. This principles weren’t based on science so much as they were based on practice, and as a result different guilds had very different sets of principles that they taught.

Another interesting aspect of this system that is interesting to me is that progression was based on self-selection. You weren’t a journeyman because you said so, or because you took a test, but because your peers respected your abilities.

I think software development is similar. Kent Beck isn’t famous (at least to the degree that geeks can be famous) because he has a certain degree or because he is a certified Grand Master, but because we respect his accomplishments.

I wish software development was organized a bit more like medieval trades, a point that Brian Marick sort-of made at the Workshop on Technical Debt when he indicated how much we need to imprint good practices on young software developers in a systematic way. I wish we really entered the system as apprentices and were attached to a journeyman until we were skilled at the trade, in a formal way.

Software development guilds in the modern worldландшафт
I believe there are currently many different software development guilds out there. They each represent a certain set of principles they believe in and teach to each other. Because they aren’t always formalized, it isn’t always obvious that they aren’t the same. The good practices from one might become bad if mixed with the “good” practices of another, but some might transcend them all.

I think I will end this post with some of the “guilds” that I am aware of. This isn’t an exhaustive list, nor an exclusive one. Some of these guilds might be the same, but with different branding. I’ll miss a lot, and they will probably overlap. And, the point here is not so much to be precise and “right”, but to just brainstorm. Here’s what I’ve got:

The Specialist Guild

The Generalist Guild

The XP Guild

The Open Source Guild

The Proprietary Software Guild

The Command and Control Guild

The Community Effort Guild

The Waterfall Guild

The Context-Driven Guild (the agnostics!)

The Sustainable Pace Guild

The Even Monkeys Can Code Guild

The Pragmatic Practices Guild

The Agile Guild

The Test First Guild

The RUP Guild

The Experts Only Guild

What guilds do you belong to? What practices do they represent?

If you enjoyed this post, make sure you subscribe to my RSS feed!

Okay, so this is a little bit afield of what I normally write about, since I don’t normally delve into technical issues. Happily, my work life is becoming more technical and this blog is likely to follow suit, so you might expect more tech and less philosophizing in the future.

If you don’t know, subversion allows you to create “hooks”, actions that are executed when certain events occur in your subversion repository. Some of the events you can use as triggers for your hooks are commits, locks, unlocks, and revision properties changes. You can create pre- and post-hooks, which just means they run before or after the event occurs.

Some examples of how these are used: sending an email to the dev team whenever a commit occurs, kicking off a deployment after a commit, or running a bunch of tests.

I needed some of these hooks for one of my projects, but I couldn’t figure out how to do it at first. Google didn’t help much - most of the examples were really old and looked like really bad ideas. Eventually, I was able to figure it out on my own, but I thought it would be a good idea to post it.

Anyway, it’s pretty easy to set these up with Dreamhost, in spite of what the Google search results will tell you.

The problem with Dreamhost’s subversion install is that all the files are owned by the dhapache user and therefore you can’t make the .tmpl files executable (the .tmpl files are sample hooks provided with the svn install). Normally, you would edit the files you want to use, then use the mv command in ssh to remove the .tmpl files, which is what makes subversion start acting on them. Unfortunately, doing it this way leaves your “hook” with no permission to execute, and you can’t change it.

So, the easiest thing to do is to first copy the hook template you want to use to a new file with no extension (post-commit.tmpl copied to post-commit, for example) and edit it as you like. Then chmod it to 755 and it will work.

That’s all it took. Now, if I exposed some security flaw hopefully one of my readers will know and tell me what a moron I am. I’ll appreciate that.

If you enjoyed this post, make sure you subscribe to my RSS feed!

As many of you know, I am the managing editor of the Association for Software Testing’s magazine, temporarily titled “AST Updated: Smart Stuff for Career Software Testers”. The current issue, of which I am particularly proud because of the steady improvements we’ve made over the previous issue, is available for free download from AST’s site.

There are a few really cool things about this issue. First, we launched it as a paper magazine at CAST, AST’s annual conference. It was really cool to do that, and it sparked a lot of interest in potential authors and advertisers. If you, like the CAST attendees, are interested in either, shoot me an email at dave@techdarkside.com.

Another really cool aspect of this issue is an article I compiled from a controversial email discussion I started about common myths of software testing. The debate got so hot and acrimonious that at least one person left AST over it! Naturally, this left plenty of good stuff for me to publish, and you’ll like the graphical theme I applied to the piece.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Mobius Labs is once again hosting Mike Kelly and I for Exploratory Testing in Practice. This time we’ll be presenting a three-day version of the course. It’s an experiment that may permanently change the format of the course if the feedback is positive. The first time we provided the course it was only two days and several participants requested an extra day.

This course is a lot of fun as an instructor and an attendee. I like giving it because there are no bullets points to read - our slides are titles and pictures and that’s it. It’s an approach I borrowed from Matt Heusser, and I like the effect as a presenter. It’s just you, the topic, the picture, and the audience. If you don’t know what you’re talking about there are no bulleted lists to hide behind.

I think this approach is good for the attendee as well - the feedback we’ve received supports this idea. It’s less boring this way, because the instructor’s engagement level evokes greater interest in the attendees.

At any rate, the course is a valuable way to learn the session-based approach to exploratory testing. It is a good course for testers of all levels, including your business partners who perform acceptance testing of a “finished” product. The mix of lecture and practice helps you transition from book learning to practical experience - in the class we test real software, which helps cement the concepts we learn in class as working practices.

To read more about the course or to register for the August 26-28 course in Indianapolis, visit MobiusLabs.com.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Your Job Stinks but You Can’t Leave, What to Do?

It can be a desperate feeling; you’re making just enough money to be fairly comfortable but you hate your job. What should you do? You almost don’t want to rock the boat by interviewing for new jobs because you don’t want to perpetuate the vicious cycle of starting anew, again, and finding out that you hate this job as much as the one you just left. So should you just grind your teeth and stay put? If you do stay then you need to retool your job and come up with some ways to make it bearable. Here are a few tips for you to consider if you’re going to stick it out at your job:

Make some new friends. Chances are there are going to be people feeling the same way you do. If you’ve always avoided going out with the work crew for a few beers at the end of the day because you never envisioned staying on at the job it’s now time to suck it up and go for a few. This is a way of networking that you don’t really hear too much about. You’re not networking to find a job but to find people that you can bash your job with. It will make you feel better.

Avoid your boss. That is all you have to do. Figure out his or her schedule and refrain from making eye contact. It’s really not that hard and you’ll feel like you’re in a movie as you duck down hallways or into other cubicles to avoid talking with the jerk.

Save your money. Start socking away a little more money each week so you won’t have to stay at this job if it really becomes too unbearable. Consider it your ticket to early retirement even though you’re not going to retire until you’re dead or 80. This will be your reward money for yourself once you do eventually quit and move on to a job that you know will be better suited for you.

Treat your family like you love your job. The worst thing you can do is bring your hate home with you. Your spouse and kids will hate you. It’s that vicious cycle thing again. Just bring home the paycheck and they’ll be happy.

Waste time as much as possible. If you’ve been at your job for even a couple weeks then you’ve probably already figured out the times that you can screw off and when you can’t. If you’re going to be stuck in this job then the least you can do for yourself is figure out the best ways to pass the time.

This post was contributed by Heather Johnson, who is an industry critic on online college reviews. She invites your feedback at heatherjohnson2323 at gmail dot com.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Most career advice sucks at least 50% of the time. Context matters when it comes to advice because most career problems aren’t simple enough for generalities to work very often. Buy a house. Have kids. Don’t lease cars. Good advice? Sometimes, not always. For career advice to be really useful, it has to context imperial. No matter what the context, it has to work. Unfortunately, advice that fits this requirement is usually pretty lame.

So here are two pieces of advice that I think are pretty useful in nearly all contexts within IT.

1) Don’t schedule a presentation to senior management on the same day you get braces glued to your teeth, unless you want the director of application development to whisper “I tawt I taw a puddy tat” whenever you leave the room. I wish that hadn’t just happened to me YESTERDAY.

2) Don’t use waterfall for software development projects. Unless you want to spend huge amounts of money, deliver nothing, and go down with the ship insisting you would have been successful if only the business hadn’t kept changing requirements. Flippin’ baby.

If you enjoyed this post, make sure you subscribe to my RSS feed!

I’m pretty much allergic to any form of requirements documentation. Change control makes my skin itch, and big up front planning makes me vomit. But I also am not totally comfortable with winging it all the time. As a project manager, I need to get a sense of how big the project is, what are the pieces and parts, and how will the product be used. And I need it fast, flexible, and without much overhead. Oh yeah, don’t forget I have to also be able to use it to plan iterations, drive development and testing, and report status. All without making comprehensive documentation more important than working software or processes and tools more important than individuals and interactions.

That’s why I’m glad I discovered User Stories Applied: For Agile Software Development by Mike Cohn. It is a short, practical explanation of how to plan, estimate, and execute an agile project with user stories. These lightweight requirements never get in the way or replace conversations with users and customers. Instead, they help you keep track of what you’re going to build and serve as a reminder to talk to SME’s about what they mean. You can use them to report status, to plan iterations, and to get an overview of the product’s feature set.

I wholeheartedly endorse this book for all project managers.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Man, it sucks to get hacked. It’s the second time it’s happened to me, and I don’t like it. This time the mess took longer to clean up - I owe a big thanks to Bill Young, the best developer ever, for fixing me up. Thanks Bill!

If you enjoyed this post, make sure you subscribe to my RSS feed!

The vast majority of open source projects are horizontals - they solve a general type of problem rather than a specific problem itself. There are open source document management systems, open source content management systems, open source office productivity systems. Hopefully you get the idea. But how many open source insurance policy systems are there? How many open source telco billing systems are there? There aren’t a lot of open source enterprise solutions out there. Platforms, yes. Solutions - not yet.

That is, not until Collaborative Software Initiative and the State of Utah open source UT-NEDSS, their web-based infectious disease reporting and management system later this year. Can you get any more vertical than that?

Here’s a quote from a recent press release about this project that I think highlights the value of applying open source approaches to vertical problems in the specific context of infectious disease management:

“The project is a perfect example of how collaboration in software can have an impact on society – in this case, we can help prevent the spread of disease and improve quality of care for patients by developing a system that works for everyone,” said Stuart Cohen, CEO of CSI. “The State of Utah is taking a necessary leadership role to begin the rollout of an infectious disease reporting and management system for the 21st century. We are very excited to enable that transition and to work with other states to deploy this important system.”

???????? ????? ????????

I think vertical open source solutions like UT-NEDSS are going to have a very important role in the overall IT landscape in the future. Enterprising organizations and individuals who can take open source platforms, apply them to vertical problems, and then release them to the programming world are going to be major players in shaping the software industry. I think it’s really cool. And I’m proud to be involved with this project, even if it’s just a minor role.

If you enjoyed this post, make sure you subscribe to my RSS feed!