Tuesday, August 25, 2009

I enjoy acting, but what I really want to do is be a director!

If you've ever watched interviews with actors, it's almost invariable that at some point they'll utter the phrase "While I really enjoy acting, what I really want to do is direct." It's almost comical in it's predictability.

The thing is, programmers aren't much different. At least that was the case at my former job, where rampant title inflation meant that the title of 'Director' was roughly equivalent to a lead anywhere else. Of course, in that context, 'Director' meant 'Director of Software Engineering' or 'Director of Technology' or something. Forgetting nomenclature for a moment, though, there is still the common that many a programmer has toiled away in obscurity day and night only to suddenly see one of his co-workers elevated to a higher position for no discernable reason. Now at my old job a lot of it had to do with politics, but I even there it caused to me think about a few very basic questions, namely, what causes one person to rapidly ascend the ranks, while another toils endlessly in obscurity and how, as a manager, do you make sure that you promote people who are truly deserving and who don't merely appear to be deserving?

Most software engineers expect that promotions should be based on merit. Of course presumes that the world is a fair place, which I think most adults accept as a laughable assertion. I suspect there are no professions where promotions are based soley on merit. It's especially grating for hard working programmers it's usually not necessarily the most skilled or hardest working person who's promoted, but rather the one that *appears* the best.

Now, often such promotions will be chalked up to 'politics', and I think that's a fair point. As I said, at my last company most of the promotions were. In such instances, there is little one can do. At the same time, however, there is a ring of fatalism to such statements. By using 'politics' as an excuse you are essentially saying you have no power to affect change. The word also implies that those promoted are completely undeserving of promotion. I'll cop to the fact that they may not be the most deserving, but more often than not they are doing something right.

Having now managed a total of somewhere between 70-100 different individuals over the course of the last 3 years, I myself have "promoted" the wrong people a number of times. In most cases, I didn't even realize my mistake until it was too late. That probably says more about my own failings than anything else, but it is interesting to go back and ask myself why I made the decisions I did.

One telling example is from one of my more recent projects. It was a large migration effort from an existing software stack to a roughly equivalent one. There were a total of about 25 programmers, half onsite, the other half offshore, all formally reporting to me. We had about 3-4 Scrum teams. We had a few leads already established, but due to some reorganization of teams, we needed a few more. This is where I made some flat out bad decisions.

One of the new leads, whom I'll call Jason, was picked based on merit. By at least one of the senior programmer's accounts he was 'the best programmer on the team'. I heard some grumblings that he did things here and there that were a bit goofy, but for the most part everyone agreed he turned out fairly solid code.

Of course, I thought giving him more responsiblity was a no brainer. But soon questioned my decision. He could not delegate work to others, instead having to do it all himself. He would make commitments to a given schedule, saying it wasn't a problem, only to later reverse himself and start saying he had too much on his shoulders. I never had any faith that when he said something was a 'day from being done' that it was anywhere near complete. He took a great deal of time escalating minor issues to me that I thought he should be handling. When the project ended he left, of course, but had he stuck around his performance would have caused me to put him back in a purely dev role and remove the extra responsibility from his shoulders (i.e. I would not have formalized his promotion).

Now the other lead, who I'll call Scott, was mostly self-selected. He had a military background which tended to make him a bit more authoratative, more familarity with Scrum (which was generally lacking on all teams), and he seemed to 'know what was going on'. When I asked him how things were going he gave compelling, concise answers. He made decisions on his own rarely escalating to me, help coordinate onsite and offshore resources, and I largely stopped worrying about his teams progress. I *trusted* him.

The thing of it is, though, Jason (though hardly a leader) was less of a disaster than Scott. From his utter panic, constant escalations, and inability to meet targets, I *knew* his stuff was in a bad shape. He *was* a failure as a leader, but I *knew* it and so could work to mitigate it. In constrast, I didn't know Scott had been a disaster and his team was totally off track until *after* he had left. Where he had been saying 'things are almost done', they were not even close. Looking more closely at his work, he had made bizarre arbitrary decisions that according to him were 'best practices', yet flew in the face of every internal convention established within the company. What's most interesting to me is that he had the classic qualities one looks for in a leader, the type of personality traits that cause one to be promoted. The problem was that his underlying decision making, the real crux of what he was doing was complete crap.

I'm not sure I have a great answer as to how to ensure those promoted are the right people. The obvious answer is to is to look closely at the work the person is doing, but a large portion of hte time those making decisions about promotions don't even have to the techincal background to make such an evaluation. Even for people like me, though, it's really easy to say that you'll look carefully at every line of code and every decision and quite a bit harder when you are managing large teams. When you have 20 or 30 people reporting to you on multiple teams, you have to choose where to direct your efforts or you'll get nothing done. When someone seems to be making the right decisions, who's reporting good progress, one is inclined to accept it. In the example mentioned above, I felt all my time needed to go to managing Jason, whereas Scott had things under control. I thought if I spent time on Scott, I wouldn't have enough to keep Jason on track. Scott made my life easier, whereas Jason ate in my time day after day. It's only natural that a manager will look kindly on those who seem to make life easier.

As for what you yourself can do to help raise your visibility, they're again simple things on paper. Don't escalate every tiny issue to your manager. Follow through on your commitments. Don't get angry (this has always been a big one), when people seem to make unreasonable requests, and try to say 'I'll see what I can do'. And more than anything else, market yourself. If you're not making others aware of your accomplishments, it's unlikely anyone else is. That's not to say you should negate what your team is doing, but an offhanded word here and there goes a long way. You may feel like a car salesman, but no one will look out for your best interests but you. Again, as with all things, on paper this stuff is easy.

In the real world, it's tough as hell.

Thursday, August 20, 2009

The Devil's Advocate


If you've read the excerpt from the book I'm working on, you'll know the last place I worked was at times a really miserable place to be. And the low point was when the person I have come to refer to as 'John' started to slowly take over our tight-knit team of developers. In a response to criticism over that initial excerpt, I also wrote about John's interesting use of the term 'Devil's advocate':


You have to understand how truly awful an experience it was to be there during his rise to power. He actively marginalized people like Andrew and I whom he saw as a threat. We had established ourselves, we were his competitors in some sense. He actually *disinvited* Andrew from the team offsite and then made reference to people he called "Devil's Advocates". These were people, John told us, who stood in the way of change and improvement by always offering up reasons things couldn't change. He then told us that someone had been disinvited from the offsite, because he was one of these characters. Since Andrew was the only one not there, it was pretty obvious to whom he was referring. This was just before Andrew was transferred to the 'technology' team, which consisted solely of Matt. I'm fairly certain the whole thing was an attempt at removing Andrew from the group so he'd have no base of power.

At the time, I viewed this label as a fabricated pejorative, created only to discredit the people who opposed John. Anyone who didn't agree with him, even if he had a valid criticism of John's ideas would be labeled one, much as people were labeled 'Communist' during the McCarthy era even when they probably didn't even know who Marx was.

Ideas stand on their own, however. I've never denied that John was a very intelligent guy and that he introduced a lot of great ideas to the development team. He was the first person to really bring unit testing and TDD to the forefront, he helped push for things like using Bugzilla (rather than Excel), and a number of other really great improvements. It didn't make him any less of a bastard, of course.

The concept of the Devil's Advocate never struck me as one of these valid ideas. I classed it as one of his attempts at manipulation and back-stabbing. As much as it pains me to admit, though, I've now come to see some validity in what he was saying.

The company I'm at now is a bit larger than that company was and most of the staff have a good deal more professional history. There are a lot of great people who've been around for 7 or 8 or even 9 years. But there's also a lot about the process and tools that I'd love to see change. It is a very meeting-oriented and management heavy company. And I think some bad practices have been around so long that the real veterans can't even imagine that there might be a better way to do things.

In my first two years here, changing some of these behaviors was my biggest goal. I felt that I made progress, but never quite as much as I would have hoped. Recently, I was put on a new team and it feels like I'm now back at square one.

Whenever I join a new team, I mostly keep my mouth shut, observe, and try to think about what I think can be improved. I don't presume to have all the answers, but I *do* have opinions. If was wasn't going to change anything, I really don't see a huge amount of value in what I do. My day-to-day activities, such as updating Excel sheets with who's busy with what, could be done by a monkey. My real value is in helping people to see a better ways of doing things.

Which brings us back around to the Devil's Advocate.

As I've started to feel a bit more sure about myself and a bit more vocal about things I think need to change on my new team, such as the meeting culture and etiquette or how we do estimation there are a few of the 'veterans' who will always point out that things can't change. They have a million and one reasons.

Many of them are valid. All are based on experience.

At the same time, though, it's not constructive. It seems to me almost completely reactive, a recalcitrance that seems to say 'Yeah, things suck, but they have to suck.' I just don't buy that. Things can get better. And this constant complaining about any new idea doesn't really improve things, it keeps the team and culture from evolving. To me it would be as if our prehistoric ancestors had said:
'Hey, this bipedalism thing is stupid. We don't need to walk upright. We're doing fine walking on all fours. Plus if we walk upright, our hips will narrow and it'll be really dangerous for women to give birth. It's probably going to result in a lot of people having back problems too.'

All valid concerns. Every one of them.

But, you see, walking upright allowed us to carry things and use our hands freely, which then led to things like creating tools, and so on. Things are never so simple as they seem. You can have a valid concern and yet the averseness to change still keeps you from evolving into something better.

Back to the present day. The Devil's advocate on a team can often make it difficult to implement change. He's always pointing out all the flaws, criticizing new ideas, yet rarely is offering his own alternative. But the real question is this:
What do about this if you're convinced a change needs to happen?

The thing you don't do is use the label out-loud and attempt to marginalize people as John did. These people *do* have valid concerns as *incredibly* frustrating as they may be. My general approach is to talk to the person offline about their concerns so I better understand them. Sometimes I'll realize I need to reevaluate my own conclusions. I try not to *automatically* assume I'm right and sometimes these people offer me valuable insight into the flaws in my own thinking. Debate is healthy, it's not something to be avoided.

I do however get frustrated, though. After all I readily admit I'm a fairly stubborn person and often it's difficult to sway me from an idea in which I have conviction (not saying this is good). In these cases, if I may slowly try to implement minor incremental change that will go unnoticed. I try to talk to others in my group and convince others (particularly people of authority) of the value of the change so as to create a groundswell.

And then sometimes I just give in. But this is only if it's apparent, that it's a hopeless battle or I don't feel the reward is worth the effort. I'm usually pretty disappointed and angry when this happens. But then failure is part of life.

Sometimes acceptance is the best you can do.

Saturday, August 15, 2009

Response to criticism of book excerpt

I got a few positive comments on the last post which contained an excerpt of the book I'm trying to write (when I don't get distracted writing stuff for this blog).

I also, however, got an email from someone essentially saying that he felt the post was so full of anger that it had him looking critically at me. I'm guessing he was trying to evaluate if I was so blinded by my anger that I was no longer objective. He'd hoped for more of an objective, didactic tone, logically examing the reasons for the successes and failures of the company.

It's a fair criticism. I think I may come off poorly based on what I've written, but one really had to be there to understand the feelings we in the group had.

Here was my response:
Okay, so let me preface this by saying that large portions of my time at the company were really horrible, horrible experiences. When you came in to work there I'd already moved over to a new team. I was under a new boss at that point and I really, really respected him, particularly as he was the complete opposite of John: selfless, humble, always willing to discuss his ideas, and someone who, at the end of the day, took responsibility for his actions and work.

In contrast, I really do still see John as a completely amoral individual with borderline psychopathic tendencies. I suppose that may be overstating things a bit, but I honestly saw behaviors from him that I cannot reconcile with any notion of empathy or sympathy for other people. He was a complete narcissist. Ultimately only his own desires and needs mattered to him. Everything else was subservient to his desires. As long as one did not pose a threat to these desires, he could actually seem like a decent guy (I have another anecdote that illustrates this).

You have to understand how truly awful an experience it was to be there during his 'rise to power'. He actively marginalized people like Andrew and I whom he saw as a threat. We had established ourselves, we were his competitors in some sense. He actually *disinvited* Andrew from the team offsite and then made reference to people he called "Devil's Advocates". These were people, John told us, who stood in the way of change and improvement by always offering up reasons things couldn't change. He then told us that someone had been disinvited from the offsite, because he was one of these characters. Since Andrew was the only one not there, it was pretty obvious whom he was referring too. This was just before Andrew was transferred to the 'technology' team, which consisted solely of Matt. I'm fairly certain the whole thing was an attempt at removing Andrew from the group so he'd have no base of power. Matt, I'm sure, was clueless about his complicity.At the time when all the stuff from the excerpt was going on, I literally felt physically nauseated as I drove into work each morning. I was a shell. The stress had always been part of job, of course. That was bad enough. But when John came in and took from us the one thing we did have, which was hope, hope that things could get better, hope that we have *someone* who was sticking up for us, defending us, it was crushing.

Look at the comments on the blog from people who were there. I certainly was not alone in these feelings. In fact, shortly after John took over the group, we had a resume party at Andrew’s house. Every *one* of the SEs--other than those who'd joined *after* John (in my view these were his stooges)--came to update their resumes. Three of us all interviewed with the same company on the same day. Only one person got a job out of it. And the day he turned in his letter of resignation, so did another of the SEs. He was going back to the job he had *before* he started working there, the one he'd left because he was excited about being a programmer rather than just a sysadmin. He went back because he couldn't take it any more.

I honestly had a few weekends where I seriously considered quitting the following Monday. I don't mean toying with the idea, but that I came very close to just walking out. But I didn't. And the day I found out I had been moved over to a new team, and out from under John was the happiest day of my life while there.

So, you have to understand all of these things, when evaluating what I've written. For me, writing the book is as much about catharsis as anything. I and many others still carry around a tremendous amount of resentment about how I was treated. I think this is understandable, though it's not something I'm proud of. If you beat a dog long enough, he *will* turn vicious. It's inevitable. Some people are far more angry than I am. I've learned to largely let go. But the fact that I still find myself writing emails like this, or talking endlessly about my experiences at my last job to my current co-workers, says I've not completely let go. And in writing the book, I really am hoping I can let go of the lingering anger I still feel. In fact, I've quite enjoyed writing it, because while I knew about all the things that angered me, I'd forgotten about many of the great experiences I had while there. I've had to think back and remembering some of those great times has softened my view on the whole experience.

From your email, it sounds like your hope was for me to provide inside into the triumphs and failures of either the company as a whole or my own. I don't know that I have much insight into what the *company* did right or wrong. I have a few thoughts, but certainly nowhere near enough to fill a book. Similarly, I learned a lot during my time there, about what helped me succeed and what hindered my success, but to me again it's more just a journey through time, a view into a young software engineer's eyes as the company he worked for grew and transformed and all the things that occurred along the way. The lessons, well, those largely will have to be inferred by the reader I fear.

Friday, August 14, 2009

ZPlanner!

I've been using variants of Scrum for a number of years now. Now, the topic of what does or doesn't qualify as Scrum is worthy of a blog itself (and it'll get one, trust me), but this blog is about something else, namely toolsets.

I've tried the notecard things a few times, but I always end up coming back to software solutions to manage stories and tasks. And in most cases the companies I've worked for have not been willing to put up the coin to buy an 'enterprise' solution, such as VersionOne or ScrumWorks. Those look like nice, though in the case of VersionOne overly complex, products. Mostly I've just used XPlanner XPlanner as it's free, open source, and relatively easy to set up and use.

But XPlanner seems to be dead at this point. There doesn't seem to be an active development and the last release was almost two years ago. I honestly think it's works fairly well, but I do think it has a number of shortcomings

  • A story can't be turned into a task and a task can't be turned into a story. It's often the case that you initially defined something as a task, but you realize it's actually a story (or vice versa). You have to delete the original item and recreate it as the other type, you can't just *move* it.
  • Moving tasks amongst stories and stories amongst iterations uses a huge dropdown of all items within your product
  • There is no backlog. You can get around this by creating a fake iteration, but it's kind of kludgy
  • The way in which estimates/burndowns are tracked over time is confusing


There are a number of other things I dislike, but primiarly they all stem around the klutzy interface. Something that mimics more closely the ease with which one can move around notecards would be great.

A few months back my company was going through a re-org. I found out that there no long was a position for me and being a bit nervous about my future, decided I better start brushing up on my programming skills. After all I've been a manager now for a few years and after trying ot think of something useful to motivate me to start doing a bit of programming again, I decided I'd try writing my own version of XPlanner, fixing all the things I thought wrong in the original.

Since it was mainly started as a project to refresh my programming skills, I decided to try a few new technologies just to get familiar. At the same time I didn't want to just use a technology for the sake of using it. In the end, the stack I ended up with was:

  • Stripes
  • DisplayTag
  • JQuery/Ajax
  • Maven2
  • Hibernate Annotations
  • Mercurial
  • Cobertura
  • HSQL (for unit tests)

My goal at all times was to keep the code as simple as possible. To this end I did most of my work using TDD, even "breaking" sacred rules of coding if it seemed like the simplest solution. For example, both Stripe Actions and Hibernate domain objects use annotations. Since in my first case the action and the Hibernate object has the same field, why not have a single file with BOTH sets of annotations? My Stripes action and Hibernate file the same code? What?!? You can't do that!

Well, I did.

When my design started to get kludgy, only then did I split them out. Similarly, I didn't abstract much of anything to start with. I didn't think out my class design in the beginning. I just coded the simplest possible thing I could.

Using this appraoch, I actually had a working application in which I could enter stories and tasks (even with ramping up on 5-6 new technologies) in about 40 hours. Of course, I've subsequently spent quite a bit of time refactoring, rewriting tests, adding more functionality, and most of all futzing around rather hopelessly in Ajax (I suck at front-end development).

Still, I've probably put in a total of 150-200 hours of work and have learned quite a bit. And I actually have a "kind of" working application. It still needs a ton of work, but it's getting there.

Screen shot of app and Ajax-based drag-n-drop inteface:



See how few files there are. Very few config files either:



Cool dependency graph courtesy of Maven2 and Eclipse plugin:


Cobertura test coverage report:

Book Excerpt


As a few of you know, I've been working on a book about my experiences at my last place of employment.

I joined when the company consisted of only 30 or so people and over the course of four years or so, watched as it grew in size to almost 300 employees. I hadn't even realized how unique an experience it was, until a contractor who'd come in to do some work suggested I should capture some of what goes on (at least in this case) as a "start up" grows into a full-fledged company.

Here is an excerpt, which details my lowest point, when I was feeling physically nauseated at the prospect of coming in, dreading every moment I was there. For those who know the company's name and/or the individuals (I've changed them all) please keep it to yourself. The book isn't intended to defame the company or any of its employees, it's simply a rembrance of both the good and bad times, and insight into some experiences that (hopefully) few of you will ever have:

At this same time, John was moving forward with his project. Somehow Andrew ended up coming in to help here as well, even though he was still working 100 hours a week on his own project. Oddly, I quickly realized John had no interest in using my code and, in fact, wasn’t really using much of our WidgetFramework at all. He kind of was writing his own thing and most of it very specific to his needs. A year later, during one of the SE meetings, John said:

‘What would you do if we started using your redesign of WidgetFramework on every project?’
‘We can’t. It’s not ready for that. I’d need more time’
‘But what if we couldn’t get that time. How will you make it work?’

He was trying to bait me. The funny thing is, we weren’t even talking about using what he had done for his similar project. No one reused that code. And yet, somehow, by the end of it, John had positioned himself as the great white hope of the software engineering department, as an example of how to do things the ‘right way’.

Andrew summed it up this way:
'He basically did a complete shit job, then wrote a long ‘case study’ about how great a job he did. And everyone on the executive team believed him. They didn’t even have the expertise to know he was full of shit.'

Of course, I only heard about the above much, much later. At the time, a number of us were really excited when there started to be talk about John taking over the group. To most of us, John seemed like a decent guy. He obviously knew a lot about development (or seemed to). We were sure he’d do a great job in representing our concerns and being an advocate in the face of PM and customer pressure. Besides, we were sure we couldn’t do any worse than Matt. How wrong we were.

At the time, it didn’t even occur to me that it was Andrew who was supposed to have come back to lead us. We missed that entirely in complaining about Matt and dreaming about John coming in and fixing all our problems. It was supposed to have been Andrew. At this point, however, there was no reason to distrust John. Andrew and Matt, both of whom had worked with him formerly, hadn’t said anything negative at all. I wouldn’t really expect anything different from Matt, even today. But in light of discussions I had with Andrew years later about that time, I’ve never understood why the hell he didn’t say something at the time. He knew it had been John who’d turned their former company’s culture into one of back-room deals and defaming others behind doors, that it had been John that had played a primary part in sinking that company with his decisions. He didn’t tell us this at that time, though. So, when it was announced John was going to be taking charge of the group, we were all excited. Things are going to get better, we thought!

At first, things did seem to be better. John was actually actively scheduling the SE meeting, something that had only occurred rarely under Matt. And John had an agenda for these meetings and a very commanding way of leading them. He set up one-on-ones with each of us on the team, where he bring the little notebook he always carried with him everywhere, taking notes. He really seemed to have a genuine interest in our work and to be involving himself in our problems.

Of course, if one paused to examine the situation, he’d quickly see that nothing every came of these notes John took. He’d happily listen to our complaints, jot something down now and again, and yet nothing ever changed. We still had to work ridiculous hours, we were still assigned timelines before we knew what the work was, the only difference now was that when we screwed up rather than having a boss who didn’t really even pay attention, we had someone riding us asking us things like ‘What would you have done differently?’. The one thing he did do was make sure that at no point he personally would be accountable for any mistake made by the group.

What’s interesting is, I’m not really sure what John even did at this time. He wasn’t responsible for the resourcing. No, we had resourcing managers who assigned programmers to each of the projects. Oh, well, he must have been involved in high level discussions of the individual projects then? Nope, again wrong. We were pretty much left to fend for our own there as well. Really, John seemed to spend most of his time with other “people of importance” behind closed doors. What he was doing was unclear, but he certainly wasn’t helping make our lives any less painful.
In fact, things were measurably worse because before we at least felt able to stand up for ourselves. Since we had no advocate we had started to be our own advocates, to complain when things were bad, and occasionally (though very rarely) even refuse when the unreasonable was asked of us. But now, that power had been usurped. In his role as our leader, John has subtle affected the distribution of power, centralizing it in his own hands, and marginalizing anyone who disagreed or represented a potential challenge to his power.

As the leaders of the existing SE group, Andrew and I were in treat for special treatment. Andrew was safe for the moment as he was still so embroiled with his loyalty program that he was invisible to the main group, but I was still a fairly central figure. At the weekly SE discussions it became apparent that what once was a forum for open discussion has changed dramatically.

One case, in particular, was illuminating. I can’t remember what the actual point of discussion was, but John had suggested one or another change to how we did things. Having quite a bit of practical experience within the group and on day-to-day project work, I felt the suggestion had some real problems. Not realizing that the ground had shift beneath my feet, I said as much in the meeting. John took me aside after the meeting had concluded to speak with me privately.

'I can’t have you contradict me in front of the others that way'
'I thought it was an open forum for discussion, John. I disagreed with what you were saying.'
'I understand. But there’s a right way to give that feedback and a wrong way. If you have strong feelings about something, you can come to me after to discuss.'

Apparently, open discussion was taboo for John, the idea that he be thought of as anything less than infallible, his ideas less than sacrosanct, seemed to him unacceptable. Of course, with hindsight, it’s obvious why he felt this way. In open discussion, arguments had to be made on their merits, not on who had made them. This was at odds with John’s plans. Any good idea had to come from him. If merit triumphed, John might not be the victor in every discussion. He absolutely had to be on the right again and again, if he was going to centralize the power of the group in his hands. Decisions made in secret, behind closed doors could not be discussed. If you dissented and you simply came to him, he would either tell you that you were wrong or adjust his thinking, hiding your input, hiding that he was anything less than infallible.

Of course, as it was with ideas, so it was with people. John now made a concerted push to elevate those people who he trusted into positions of power. Those who represented a challenge to him, he had to marginalize. Of course, I realized none of this yet. To me our company was still a place where people and ideas triumphed based on their merit.

John didn’t use secrecy only for the purpose off deflecting criticism, of course. More and more often you’d see him behind closed doors talking with the head of the PMs. It was funny in how obvious it was, but perhaps that was John’s power. No one could ever imagine a person to be so devious, so underhanded, so we sort of overlooked these things in the beginning. He had no office, so most often you’d see John and Ed in the conference room on our floor, which was elevated, and had windows to the rest of the floor, the door closed. What they were talking about, I have no idea.

From what transpired later, though, it became pretty clear. I never thought of Ed as a bad guy, he simply was not a particularly competent individual. Though he was in charge of the PM group, he had little management skill and even less technical expertise. Mainly he had succeeded based on joining the company in its early days and having known many of its founders personally. He coasted on his charm and through the hard work of those on his projects, but whenever real work or critical thought were required he was able to contribute almost nothing at tall. He has reached the zenith of his power given his abilities and in John, Ed saw someone with the technical expertise and drive that he lacked. John was his ticket to bigger and better things.

It became clear over the coming months that these co-conspirators were attempting to centralize power and cement their positions in the company. The very same thing that has caused Ed to toss his lot in with John however, presented a major problem for him. Ed was dwarfed both in intelligence, but also in his capacity for duplicity. John, for whatever criticisms I might level at him, was brutally competent. Ed was mostly just a buffoon. That Ed ever entertained the thought of using John was ridiculous. His Faustian bargain would have consequences. John, for his part, I’m sure never saw Ed as someone who could contribute thoughts or work to his plan. He merely viewed him as another puppet, someone else through which his ideas could be proxied, and someone to clap and cheer him as the savior of the company.

It was sometime in November of that year, when I had my first real taste of what John and Ed’s collusion meant for me personally. Alex, who had now moved into a role as sales engineer, popped by my desk early one afternoon.

'There’s a problem on the big holiday website.'
'Crap. What’s wrong?'
'Well, apparently, we accidentally sent over 500 SMSes to the same woman, who hadn’t even registered. She complained, and now our South African SMS provider has shut us down. Completely.'
'Shit. What do we need to do?'
'Well, there like 12 hours off our time zone, so I don’t think there’s really anything we can do right now. I’ve contacted them and hopefully we’ll have something figured out by tomorrow. I wouldn’t worry right now.'

I had a ton of project kick-off meetings that day and knowing only too well that if I missed them, I would miss the only chance I had to curtail scope and set realistic expectations, the sensible thing to do seemed to go to the meetings, wait until Alex got back to me with an update from our South African friends, and worry about it then. Besides, I figured, if it’s a really big deal surely someone other than our sales engineer is going to come bug me: my manager, the PM for the project, maybe even an executive.

The next day I got back with Alex. The South African SMS provider had told us that we had to first give assurances that no one phone number would ever get more than one SMS message, before they reenabled it for us. I immediately started to furiously code up a solution and helped organize the effort to get it QA’d and into production. We fixed the issue by the next morning.

The next day, though, John dropped by my desk.
'Hey, can we meet for a few minutes to talk.'
'Sure John, no problem, let me just finish this email.'

As I started to head to the room. I wondered what the meeting could possibly be about. When I got there, I was surprised to see that it was not just John waiting, but for some bizarre reason, Shane was also sitting at the table. This is weird.

'So, Zac, we need to talk about the holiday website. Can you give me a brief explanation of what happened first?'

I explained everything at which point John just looked at me and said:
'So, what do you think you should have done differently?'

'Nothing', was my reply. 'I did everything I could have given the circumstances'
'Why did you wait until the next day to take action?'
'Um, well, Alex had told me we couldn’t probably even contact the SMS company until the next morning and I had a ton of kick-off meetings that I didn’t want to miss'.
'Having meetings is no excuse for not dealing with the issue. This was a big deal.'

Shane just sat there silently. As I sat there I was engulfed in rage. In my mind’s eye, I saw myself throwing the table out the way, reaching across the table and smashing my fist into John’s little bobble head as he and his little toady sat there with their little stupid smirking expressions.

This was complete and utter bullshit on a level I could not even conceive. John is blaming me for this?!? I had busted ass to fix the goddamn thing. Where had he been in all of this?

'Well, no one ever came to me saying how important it was. You didn’t. Where were you in all of this, John?'
'This isn’t about me'.

Shane still sat there passively looking at the two of us like a deer caught in headlights. I honestly still don’t blame him for what transpired at this meeting. Or rather, let me rephrase, I blame him for nothing more than not standing up to John. He knew what was going on and sat there, empowering him by his silent complicity.

I sat there nearly shaking in rage.

‘Are we done?’
‘Yes’, John replied.

Thursday, August 13, 2009

Meeting Failure!


So, after my last entry detailing what this blog would cover, specifically failure, I was asked if I'd actually post something substantive. Well, this may be a loose interpretation of that request, but this is blog about failure. Specially, meeting failure.

At my current company, they like meetings. It varies by group/division, of course. Some really aren't that bad, others are horrendous. On the whole, though, the culture is so meeting-centric you'd think you'd walked into a company five times its size of 300 people.

Thankfully the people actually doing real work (devs and QA) are spared most of the worst of it, but anyone with 'manager' in his name (this includes me) seems to spend nearly his entire day in meetings. This begs the question of "When do these people do any actual work?"

Now, because many of us spend nearly our entire day in meetings, the etiquette we exhibit is pretty crappy. If you're in meetings all day and you do have some other work to do, it's likely you'll try to do it in one or another of your meetings. It also means as you run from meeting to the next, it's likely one here or there will run over and you'll be late to the next. Lastly, since people are so busy with meetings, it's often the case that people feel the only way they can get a bit of someone's time is to schedule a meeting, even when the more appropriate action would be to walk over to that person's desk for a five minute chat.

So, after having complained again and again, I decided to write up a little set of guidelines for meetings. Of course, this is the type of thing you find on many blogs. Neat, little tidy guidelines that promise to solve all your problems.

Well, the problem in the real world is that you write something like this and well, no one listens. The last group I was in was tolerable in its penchant for meetings. The group I've been with the last three months, not so much. Sure, I've complained. Many, many times. I've now written these guidelines, which I passed along to my Director. But so far, I haven't had any measurable effect. So what does this mean? How do I react to this "failure"?

Well, I do a couple things.

If I'm sitting in a room waiting for others to show up and no one is there within 10 minutes of the official meeting start, I go back to my desk and send an email to all attendees saying "I guess this meeting isn't happening. Please reschedule."

If I'm running a meeting, I invite the minimal number of people possible.

I always show up to meetings right on time, even if it means I'm usually waiting for 5 minutes. And I made somewhat pointed comments about others being late (probably just pisses people off, I'm sure).

When it's time for the meeting to end and people are still blathering on, I stand up from my seat. I don't always immediately leave, but sometimes I do.

So, basically, I'm at least raising awareness of some of these issues. You can't mandate behavior, so in an instance like this I think the best you can do is follow Gandhi's advice "Be the change in the world you wish to see." Exhibit the behaviors you expect of others, speak up when people are acting contrary to what you think are reasonable expectations, and most importantly try to get the ear of someone in a position of authority (in my example my Director).

In any event, here are my general guidelines:
  1. Meetings begin and end on time
  2. Only the organizer should be using her laptop. The rest of the participants should either not bring them or keep them closed. Same goes for phones. Either you are present for the meeting or not. Half paying attention and half doing other work wastes *everyone's* tim
  3. Every meeting should have an agenda which is provided to participants beforehand. If yo haven't prepared an agenda, you don't get to have a meeting. An agenda can be very basic. Minimally, it should consist of a problem statement, what is expected to be decided by the meeting, and sufficient information so that participants can come to the meeting prepared
  4. Don't use a meeting when ad hoc face-to-face communication will suffice
  5. The preference should be to keep meetings as short as possible while still accomplishing the goal set out in the agenda.
  6. Only invite the people that *absolutely* need to be there. Taking a shotgun approach should be strongly discouraged as wasteful and counterproductive (it detracts from other work that participants could otherwise be doing)
  7. The corollary of rule 6 is that one should not feel obligated to attend a meeting if she feels she doesn't need to be UNLESS the organizer can make a case for why her presence is required
  8. Certain meetings are special cases and do not need an agenda and rigid form. Brainstorming sessions, etc. Sometimes free-form discussion is a great thing. This should be the exception rather than the rule however.
  9. Status meetings should be discouraged in general. If the status of a project is not clear to its participants without such a meeting something is wrong. This is the essence of the program manager's role, keeping team members appraised of status and providing artifacts. If a status meeting is required, it should not a general troubleshooting session for the issues. Those should be addressed as they arise.
  10. If you those in the meeting find themselves saying 'I think this is what person <X> said', the discussion should quickly either move on and a note made to follow up with the individual or someone should go grab the person and bring him to the meeting. It is a waste of time to guess at what people think or said.
  11. If you are able to attend only a portion of a meeting, state it to the group at the beginning and exit when you need to do so with minimal disruption.

Monday, August 10, 2009

The Unicorn King and his Magic Pot of Gold




I started this blog about two years ago with a brief mission statement. I then wrote a single entry and didn't make another entry for two years. So, it's worthwhile to again touch on what this blog is about and how I *hope* it differs from a lot of other blogs in the blogosphere.

Excuse me for a sec, I need to go wash my mouth out. Using the word 'blogosphere' just made me throw up in my mouth a little.

I love reading blogs like Joel on Software and Coding Horror. I've learned so much from those guys. The problem is, though, that 99% of the time I can't help coming away from those blogs wondering 'What the hell world do these guys inhabit and if I visit will they introduce me to the Unicorn King and his magic pot of gold?'

It's kinda the same feeling I get when I start talking to a hardline proponent of Scrum (I'm a certified CSM if you really care, so I do *like* Scrum). It's just so divorced from the reality I inhabit it's laughable. Mind you, I'm not saying it's *not* reality. It's just not the reality *I* inhabit.

In their reality, every company hires the top 10% of talent (Where the other 90% go, I don't know? I'm pretty sure I've worked with a bunch of them though).

In their reality, you tell people about Scrum and they get *it* right away. They don't argue with you endlessly, implement in a half-assed way, then butcher it as new client demands come in.

In their reality, every programmer on your team is great and there isn't any dead weight. And if there is dead weight, well you just get rid of those folks with a snap of your finger! Poof! Gone!

In their reality, when a project is not possible in a given time frame, you just explain how it's not possible and tell people "I can implement *something* in that amount of time, but there will be trade-offs"...and everyone's okay with that.

You certainly don't end up having to manage team that turns out to be 100% comprised of contractors with barely adequate coding skills. You don't find yourself in endless meetings about stealing resources from other teams because you don't have the right people on your team. And you don't get put on a project that should take a year and told to make it happen in three months.

Of course, if you said this to Jeff Atwood and Joel Spolsky I suspect they'd tell you one of two things. That you just have to stick to your principles and affect change or that you leave wherever it is you're at and find a company that supports your principals.

I don't disagree with that. But reality is far more nuanced. At least with many blogs, it's made to sound so easy. You rarely get ones about how things failed utterly or completely. This blog is for all the people who've *tried* to change things, but see little progress. The people who like me, don't want to just *leave* because, hey, I get paid pretty well and I like my shiny new M3.

Sure, you can chalk that up to me being a crappy agent of change or risk-averse, because I refuse to leave. I suppose I'm complicity in my own misery. But then I have to think there are bunch of people in the same position as me. People who read joelonsoftware and come away going "Okay, that's great. But what the hell does that have to do with what *I* experience"

This is the blog for them.

Now, that's not to say I might not say some of the same things. But I hope the difference is, I won't gloss over the reality. I'll give a bit of an insight into the total soul crushing inertia and the learned helplessness that I think most of us live with. I'll share my own Sisyphusian attempts to change things and hopefully occassionally I'll be able to tell you about something that really worked. But more often than not I suspect I'll be telling you about my failures.

You don't go back and rack your brain over and over after winning. You move on. "What is won too easiliy is esteemed too lightly." as the quote goes. We learn more from failure than we ever do from winning.

And this is a blog about failure.

Friday, August 7, 2009

Why the programming language you use should be the last thing you worry about




As I’ve mentioned before, I don’t really do much coding at work. Most of my time these days is spent greasing the wheels of a soul-crushing bureaucracy with my blood.

Well, that and attending meetings.
They are of a piece.

But occasionally I do still delve into slightly more technical stuff. Mostly it’s on my own time, but recently I’ve actually been learning a little (gasp!) while at work. I recently moved over to managing a new team. My old team used Java. My new team uses .net. I’ve never done any dev in .net so I decided to pick up a book, crack open Visual Studio and try to make myself a little less clueless.

The key word being ‘little’. As a manager, I feel it’s my duty to be mostly clueless. Otherwise, what do the developers on my team have to bitch about privately?

It’s been awhile since I’ve used anything Microsoft-related for coding. In fact, my last professional experience was using VB at my first job back in 2002. Before that I used Microsoft’s VC++ for some time during school.

Now having been primarily using Java the last few years, this is where I’m supposed to start whining about the lack of checked exceptions in .net or the way it uses “:” instead of ‘extends’ and ‘implements’ to denote that a class derives from another.

The problem is this, though: I don’t care.
It doesn’t matter.

None of the differences matter. Or at least they don’t matter relative to having good code. You see, the thing is, I’m more and more convinced that about 90% of all code just flat-out sucks. In light of this, I’ve come to the conclusion that the choice of language is largely a triviality.

Now, don’t get me wrong. I’m not disputing the assertion made by Sapir-Whorf that language affects how we think and solve problems. In Java, everything’s an object. This does have a lot of implications (good and bad). But you can write equally crappy code in an OO model or a functionally decomposed model. One may fit your paradigm, but neither precludes having a good implementation any more than the only one guarantees an elegant solution.

I’m not saying writing in 80x86 assembler is just as good as C#. It’s a snap to do text-parsing in Perl, whereas it basically sucks when you have to do it in Java. That said, I still maintain that the language you’re using is towards the bottom of the list of: things to worry about ™.

At the place I worked prior to where I’m at now everything ran on Apache mod Perl. When I started I had never used Perl and I immediately took a dislike to its simplistic, loose typing and lack of a spiffy IDE. In fact, when I was made technical lead on a new, high profile project, one of the things I and some other members of the team pushed for was that we should switch to Java.

Oh, Java has strong typing. There’s Eclipse. It has integrated unit testing. Developers will be easier to find (We were having a hell of a time finding good Perl developers). There were any number of reasons to make the switch, none of which I regard as completely wrong now. The thing is, though, it didn’t make that big of a difference.

Shortly after we made this decision we brought in our first batch of Java developers . I explained to them a bit about the project, gave them an initial implementation I had written of what they were to develop more fully, and set them loose.

They came back two weeks later with a train-wreck of obfuscated, hopelessly overcomplicated code. And it didn’t even really work. My boss after looking at both sets of code suggested we toss what they’d done and begin again using my initial prototype.

Of course, we eventually got rid of the people who’d written the code, but we kept soldiering on in Java (we did use Perl for some things). A year later we had something largely workable and a new “architect” was brought in to assess our work.

His first complaint: this isn’t in Perl. Java is not a dynamic language and doesn’t have closures. This should be rewritten in Perl.

Of course, that first craptastic implementation wasn’t the fault of Java. Any more than some of my frustrations with our old code base has been the fault of Perl. They were implementation details. Whatever we did wrongly in Java, I’m sure it would have been equally wrong in Perl. Maybe in different ways, but still wrong.

Worry about the code foremost. If you already have that nailed, then, maybe you can start worrying about what language it’s in. I haven’t seen many people get past that first step, though.

Thursday, August 6, 2009

Why DekiWiki sucks


So, it's been awhile. Two years almost. When I wrote my last entry, I was just starting a new job as a development manager, and writing the coda for my former job.

Since then I've learned an awful lot, made a ton of mistakes, changed positions within my company several times, and I'm finally ready to write another entry. You'd be forgiven if you thought it was some monumental thing that had motivated me to write another blog entry after all this time, but it's really quite a mundane subject. Sucky software.

But isn't that usually what gets you all fired up? Pure, unadulturated, suckitude. We too often take the *good* software for granted. I can't imagine myself being all fired up after two years to tell you about this great new program I found. I'd probably tell some colleagues, but I sure as hell wouldn't be motiveated to write a whole blog entry about it.

The really crappy software, though, that's worthy of a novel, a catalog every idiotic failing of its creators. Currently, my utmost hatred is directed at something known as DekiWiki.

Now, let me preface all this by saying I *love* using Wikis. In fact, one of my biggest frustations at my company is this love affair with Sharepoint and Excel that most Project Managers seem to have. They use these static documents that are written then forgotten, hopelessly invisible to the people that actually need the information, and don't even realize a Wiki can be such a great collaborative, living medium for communication.

Well, a *good* Wiki is an outstanding medium. DekiWiki, in contrast, makes me want to kill babies. Which is ironic given that it's theoretically an "improvement" on the outstanding MediaWiki. Even if you don't know the name MediaWiki you've likedly used it. MediaWiki is the thing that powers Wikipedia.

Now, the brilliant minds at MindTouch decided that MediaWiki just wasn't quite good enough. No, the lightweight markup language used by MediaWiki was far too complex. After all, who can keep track of using two brackets around a name to create and link to a new page. Asterisks to create a bulleted list? Who can remember all that complexity? No, what a Wiki *really* needs is a WYSIWYG-editor stolen from Word. After all, a Wiki is really just a Word doc anyway, right?

No, no, no, no.

People too stupid to use Wiki-markup simply shouldn't be using a Wiki. These are the same people that they have to put warnings on hair dryers saying 'Do not use while bathing' or the warning on peanuts saying 'Food allergy warning: this product may contain peanuts'. Sadly, natural selection no longer is allowed to eliminated these individuals and apparently they now need a Wiki.

So, what we get is a heavyweight Word interface, which is slow (pages take seconds to load) and clumsy. If you get frustrated with the way in which in hamstrings you, you can edit the code: in HTML. Man, I can get this table quite right. Let me edit all these trs and td with nbsp's. Great!

Let's compare what you do to add a new page in MediaWiki vs. DekiWiki:

MediaWiki:
1) Edit the page and put two brackets around the new page name.


DekiWiki
1) Click 'New Page'
2) Wait several seconds for new page to load
3) Add contents, editing 'Page Title' to have page's title
4) Goto page from which you wish to link to new page
5) Click 'Edit Page'
6) Wait several seconds for page to load
7) Right click and select 'Link to page'
8) Wait several seconds for window to populate with existing pages
9)...

There are a few more steps before you're done, but I'm too tired to even keep typing them. I think you get the point.

So, in the name of making things "easier" (God forbid someone spend 5 minutes looking up Wiki-markup), anytime we want to add a page it takes 10 times as long. Great! It also has the wonderful side-effect of crashing certain browsers. That someone thought this was an "improvement" simply baffles me. Unfortunately, I think a lot of software shares this trait. Improvement to make it easier, that just makes it crap.

Normally, I wouldn't care, I would just use MediaWiki. Hell, my company has MediaWiki installed, so I'm all set.

Except for one problem, my company also has DekiWiki installed. And in the name of standardization (after all, we can't have people using different tools. It's chaos!) has decided to standardize on a single Wiki.

Guess which one *wasn't* selected.

The people doing the selection are people decided the Troubleshooting guides they used for production issues were too hard to locate, so they wanted to put them on a Wiki. And, you know, really a Wiki is just Word on the web.

But that's a topic for another blog entirely...