By isolation, I don't mean that you are locked in a box like a shut-in and never see or communicate with anyone else, I mean you're involved in a project where you are the only, or one of the only, IT participants.
By boring, I don't mean that the code is unexciting, old or simplistic. I mean the stuff that is inherently related to the code you're working on but that a lot of developers still don't really consider to be code related; for example, user acceptance tests, test plans, user documentation, returning that loaner laptop you requested because you had a consultant on-site for specialized assistance, all the things that you have to do that you you keep putting off or just plain forgetting about because secretly you give a mental groan and say to yourself, Crap, do I really have to do that? Can it at least wait?
Now, your experiences and opinions may be different, obviously. You may live to do these things because you love them or find great satisfaction and make it a point of pride to do them. If so, more power to you. You have a firm gut-level grasp of something that I think most of us don't have and I truly, honestly, want to be like you when I grow up.
Things like I describe above have one thing in common. To some extent or other they seem to live in a murky, no-mans land of it's an administrative task but not really. I'm sure you can think of a lot more examples than I gave off the top of your head. You might throw in dealing with a ticketing systems for things like change control, or whatever. The point is, these tasks are almost universally despised and the majority of people would foist them off on someone else if they had a chance.
They also have one other thing in common. Developers that don't appreciate their value and dread doing them do so because at some level they disdain them as pointless, or at the very least low value, tasks. They are things that take time away from your primary job duty of creating awesome code that everyone ooh and ahhs over. I mean, seriously, who actually wants to write a test plan, or put together a set of UAT's because the customer, whoever that may be, doesn't have a clue how to do it. They may honestly think that it really isn't their job to write UATs or worse yet, thinks its beneath them to do it, they are the customer or they're too busy actually making the company money instead of just being a necessary evil and sucking money away from the company.
However, I submit to you that these things are not annoying, ancillary tasks that any monkey could do and aren't really part of development. They are not administrative. They aren't even a necessary evil to be tolerated and grudgingly taken care of, like smelly laundry or the cat's litter box. They are just as much a part of development as actually writing code.
My personal feelings are that these types of tasks, by and large, tend to slip through the cracks in inverse proportion to the size of the team working on a project. The larger the team, the less often they tend to get ignored or slip through the cracks but the smaller the team, the more often they get ignored, put off or just not brought up at all.
I think there are several contributing factors to this;
- The fewer the team members who are capable of reasonably doing these tasks, the higher the workload on the team members who are
- The smaller the team, the less disciplined the team process is
- The smaller the team, the easier they are to jerk around
Now, looking at the first reason, I might be lucky if you didn't suggest naming the Blog Captain Obvious Q&A Time. I mean, no shit, the fewer qualified people to reasonably handle the same number of tasks increases the overall workload. But it's also so obvious that if I left it out, people would be letting me know what an idiot I was for not mentioning it. Also, given the nature of the tasks we are talking about, it's a reasonable answer. In the examples above, why couldn't some of the totally IT clueless people take care of at least some of them? I mean, do you really have to be IT Savvy to return a freaking laptop??
Of course not, but that's where the reasonable qualification comes in. When that consultant comes in to do his specialized task, who is he going to come to in order to get set up with a network login, laptop or whatever else he needs to do his job for the next week or two? Even if he's working at the elbow of the end user he will probably not be asking them to set him up and even if he did, what are the odds that the end user will take care of it himself rather than sending him to the only IT related team member?
Frankly, you probably want to take care of it yourself so that you know for fact he is ready to go, has all the proper access rights and whatever else he needs. Why, you ask? Because when he (or she) leaves, most organizations have much greater odds of failing to properly shutdown/delete everything that was opened / created for the employee coming in. The end user will almost certainly simply turn in the laptop and think it's over. You will probably be inclined to double-check that all of the ancillary tasks are taken care of; accounts suspended or removed, software licenses that may have been temporarily issued are return to the pool, etc. Especially since you were probably the one who had to request all that stuff in the first place! And lastly on this reason, remember the saying, 'If you pack it in, you pack it out'. You probably set it up in the first place and are probably in the best position to make sure that it's torn down properly. If nothing else, it's just good manners.
The second reason is again pretty obvious. The smaller a team the less need there is to have a formal process, especially if everyone is local. Communication is a snap, just yell over the cube, have an informal stand up while sharing a burger at lunch, throw a paper airplane into the cube with a note on it or put a sticky note on their forehead while they pretend to work from their corner cube. These techniques tend to become less effective the larger and more physically dispersed the team becomes. This is known fact. Also known is that humans are lazy creatures. I am not a representative example, I am far lazier than most humans, even developers, a poster child for the deadly sin of sloth, to be honest. However, most humans will give in to their level of laziness if given a chance. The smaller the group, the more likely it is that one member slacking off will affect the rest of the team. One of the things that makes pair programming and good code reviews effective is that you have lots of eyes on your code. The more eyes the more likely the code is to be good, or at least be improved significantly from where it started. Same thing goes for the little things. If I know that no one is going to look at my test plan until we are ready to run UATs on the project, the more likely I am to treat a test plan as some sort of third class citizen. This usually means it gets ignored as long as it possibly can and then crammed one together at the last minute, hoping that some crucial test didn't get missed.
The third one is all me. I have no evidence or numbers but I have been involved in a lot of small development teams. Quite frequently I was the only team member that was actually in the IT department, so obviously, this one is extremely biased. However, it does seem to me that the smaller the team, the more they get jerked around. Let's face it. We all know that typically there is strength in numbers, even for developers. This is why a lot of herbivores herd, right? Larger teams look more intimidating to end users than small ones. These predators will hesitate to bring a last minute change or tell the development team that they should be the ones writing the UAT cases if they have to face a dozen developers to do it. In most companies, politically speaking certainly, smaller teams almost certainly have no clout. Saying no becomes significantly more difficult. This is not the case in the ideal world, obviously, but we don't live in the ideal world, we live in the real world and the real world just isn't that happy. There are exceptions, absolutely, but they are exceptions, not the rule.
OK, so now that I've said all that stuff, what's my point? My point is that all these annoying, trivial, and small (or not so small, sometimes) issues that you normally don't think about become even more important in small teams. Yes, it sucks, yes, you may have to force yourself to be more disciplined than you have before and sacrifice always hurts in some way. So why do it? Let's look at what you gain.
First, it's just professional and I'm trying to become better at my profession. If you want to be good at your craft, you should be good, or at least improving, in as many aspects as possible, not just the parts you like. That's what makes it a craft. If it's just the parts you like, you're a hobbyist, even if you're getting paid for it. Don't take my word for it, go read some books from some of the actual smart people in the industry that give advice on how to become a better developer, like Martin Fowler, Uncle Bob Martin, Kent Beck, Erich Gamma, Donald Knuth, and gobs of others. They focus on a lot more than just writing code.
Second, people notice. Maybe not all the time and maybe not at first but your end users truly just don't give a damn how cool your code is (we all know this) because they can't relate to it easily. If they could, they would probably be in IT instead of running a sales team or travel agents or a risk management group or whatever they do. BUT, they can and eventually will relate to the kinds of things I've been talking about. I mean, I can go crazy fancy with putting together a UAT or use case or test plan or documentation but at the end of the day, I can also be as lazy as possible while doing those things. I don't need some huge, comprehensive document that could be used as a doorstop. I could do all those things with a simple spreadsheet. And that, my friends, they will understand. They can relate to that since they almost certainly use spreadsheets on a daily basis. If you consistently deliver things like this when they are needed, they will figure out that while you do some mystical crap they don't get, you're still one of the crew, a professional, even if you do act or look a little different.
This has so many beneficial side effects that I doubt I could think of them all. Anytime you have a chance to raise the awareness that developers are professionals too, take it! It's a huge win for everyone, not just you, or even your IT department in general but for that business unit. Because it opens that business unit up to the possibility of closer and better collaboration. And trust me, if you don't immediately see the benefits of that, let me know where you work because it must be a fantastic place!
Also, as an aside, you're also building up the political clout with that client to be able to say no and actually have them listen. If they respect you as a professional, they will start to listen to your opinion and why you're telling them no.
If you've made it this far, I would like to encourage you to post questions, contradictions, ideas for questions or whatever.
No comments:
Post a Comment