Thanks to the modern Integrated Development Environment (IDE), building software is easy. I'm not talking about writing software, that will continue to be challenging for a while yet, I'm talking about the actual compile step. Let's use Visual Studio as an example: Not only can you compile your code, but with the use of pre-build and post-build steps you can put all the work needed to build your software right there in your project file. What could be more convenient? In fact, it's so convenient that many developers never even question whether it's a good idea or not.
Building software well is hard. A comment last week from Christopher Painter at DeploymentEngineering.com reminded me that I've wanted to write this post for awhile. It never ceases to amaze me that developers will go on and on about "loose coupling", "high cohesion", and "inversion of control" and then turn around to violate all those principles by coding deployment instructions into their project files. We talk about loose coupling in development because it gives us flexibility and makes maintenance easier down the road. Aren't those good principles in a build? High cohesion is a nice attribute that essentially means "things that are alike are together". Hmm, I'll take a shot of that in my build. Don't even get me started on Inversion of Control. The fact that a developer would accept the added complexity of an IoC container and then balk at the idea of using a separate NAnt script or MSBuild file for their build stuns me.
Here's a radical thought: Your build is software too. Your build should adhere to the same principles that your software does. Your build needs to be maintainable. Your build should be self-documenting. Your build should provide good feedback to the user. Your build should be easy to run.
So take a look at your build today and see if it represents your development principles. Practicing what you preach (and doing so consistently) is the hallmark of a Big Swinging Developer.
One of my team members recently said that he was looking forward to the day when everything runs in the cloud so he no longer has to do sysadmin work. He said this at a time when he was configuring some VMs to create a test environment for our large enterprise application. I didn't think much of it at the time, mostly because this guy is a really good sysadmin and the configuration was a little bit of a time sink but didn't really get in our way.
I started thinking about his comments more when a member of someone else's team ran into a driver problem. He went from "it's not working right" to "I may have to reformat the box" in less than a half a cup of coffee. This led me to thinking about some of the other teams and how they worked for more than 2 years using only a shared environment because no one felt comfortable enough with setting up individual environments. To be fair, our environment isn't exactly trivial. We have a mix of IIS web services, Tibco EMS, Oracle, and Active Directory. At the same time, there's nothing really exotic in there. These are not only standard technologies, but every one of them can be downloaded as a trial version online.
Driving home last night I realized that I wish every developer had basic to mid-level sysadmin experience. The ability to not only set up environments from scratch, but to troubleshoot (in a logical way . . . one that doesn't start with, "Well, gotta set it on fire first.") and fix problems. This skill also helps in a corporate environment since you'll either have to work within the network bounds, work around the network limitations, or both. That ability only comes from understanding how things really work.
Being a Big Swinging Developer is all about being valuable in whatever environment you're placed. If you have some sysadmin tools in your toolbox, you never have to be the one sidelined by what turns out to be a speed bump rather than a true block.
As technical professionals, developers are often accused of ignoring human issues and focusing too much on the technical aspects of a solution. Hugh MacLeod said it best:
Habits, values, and attitudes, even dysfunctional ones, are part of one's identity. To change the way people see and do things is to challenge how they define themselves.
Being a Big Swinging Developer is all about changing the way that people see and do things and that second sentence up there explains a lot of the resistance you'll face. It's not enough to show people what they can do, you need to show them who they can be. For example, I know lots of programmers who love agile development techniques and have trouble getting others to follow suit. This can lead to a lot of frustration as the Agiles think that the Non-Agiles "just don't get it." I don't think that that's the case. I think the folks who resist agile techniques do so because they don't want to be agile developers. Really, it may be as simple as that. Not everyone wants to code quickly and safely, or be able to change their mind, or do the things that agile techniques enable. If you look at it that way then you start to realize that someone who codes slowly and (at least in their mind) carefully will view writing unit tests as extra work that lowers their productivity. They may see putting prototypes in front of users before all the requirements are known as opening themselves up for (gasp) more work down the road.
If the view of people defining their identity by their habits, values, and attitudes is correct then the happier they are with their identity, the harder it will be to change how they see and do things. This may explain why the multi-decade veterans stick to their ways while the freshly minted grad will try out whatever you throw at him. It's not that the new guy understands better, it's that his identity isn't as firmly cemented which means changing what he does results in less of a change of who he thinks he is.
The next time you have an idea for process or organizational change, make sure that it either fits with who the organization is or who they want to be. If it's going to be a significant departure then spend extra time painting the picture of who they can be if your change is adopted. If you can't sell the idea of the new identity, chances are you won't be able to sell the technical aspects of the change. If, however, you can make people want to be who your change enables them to be then you'll find yourself surrounded by support instead of resistance.
As the name implies, The Joel Test: 12 Steps to Better Code has 12 parts to it. That makes this the last parallel Big Swinging Developer Test question. Just joining the test? You can start from here and marathon it like an HBO series on Tivo.
The Joel Test: 12. Do you do hallway usability testing?
The Big Swinging Developer Test: 12. If you see a usability problem, do you treat it as a defect?
Check out the Wikipedia definition of usability. At the time of this writing the first sentence says, "…the ease with which people can employ a particular tool or other human-made object to achieve a particular goal." There’s a lot of other text that follows, but I think that the first sentence really nails what you should be measuring when you think about usability.
If we accept that definition of usability, then a usability problem is one that makes it hard for someone to use your software to accomplish a goal. Notice that this has nothing to do with fulfilling a functional specification or a passing a suite of automated tests. That’s what commodity developers do. If you see your job as writing code to fulfill a requirement or close a defect then you can easily (and cheaply) be replaced. If you see your job as building software to help other people kick ass then you’re well on your way to being a Big Swinging Developer.
If you’ve read at least a few posts on this blog, you’ve seen that it’s almost all about behavior . . . the behaviors that have helped me become a valuable developer. This seems like a good time to ask about what you’ve learned during your career. Even if you’re not a "blog comment type of person", take a moment to share some of your experience and wisdom in the comments below. Thanks!
and something I read back on page 27 is haunting me: