How Burned Out Are You?

When it comes to career burnout, I've been a student for a couple years already. During that time, I've been able to reflect on my career and learn some useful information about burning out. There are many factors affecting burnout, most simply is working too much and not having any time left for yourself. But it all boils down to a few simple questions:

• Am I as excited about my future here as I was when I started?
• Does the situation look likely to improve in the time I'm willing to wait?
• What aspects of this job are the most frustrating?
• How would I like to change them?
  

I like to look at burnout not as a yes/no proposition, but as a series of levels. There are many different aspects of work which you may be tired of. Let's look at my case as an example.

• Customer: NGA. Typical government agency full of bureaucracy and political agendas. Not the best environment to develop software in.
• Project: GeoScout. Multi-company effort to overhaul NGA's hardware and software. The problem is that no one understands what it does now, so it can't effectively be rebuilt. Plus the development is hosted on a virtual server halfway across the country on a shaky network. Need I say more?
• Company: Lockheed Martin. We keep trying to make everything like making rockets, and you know what? It doesn't work very well. But our main job is convince our customers that we are doing a good job, so they keep hiring us. Joy's Law is definitely in effect here, but no one seems to notice. "We Never Forget Who We're Working For." Yeah, not me.
• Location: Colorado. Can't say too much bad about Colorado that can be said about any other big town. So there's one aspect of my career that I can probably keep. Although Ireland is looking very nice this time of year, or I'll have to buy a snowblower.
• Industry: Software Development. Well, to be fair, government software development. Most of my complains are with the way we're told/forced to do our jobs, when there are obviously better ways to do development out there.

In assessing my burnout, I decided to make a small change first and see if it made a difference. I still believe that I like developing software, so I wasn't ready for that big of a change yet. I also wanted to give the company a second chance, so I merely changed projects within the same area. It was a safe option, and allowed me to assess some of these aspects from a second perspective. I still haven't reached a permanent decision yet, but I've got a lot better view of the situation now. I'm planning one more effort here, then I'm on my way. Email the CTO? Sure, why not?

UML and Paralysis by Analysis

Taking a break from Government complaining and back to work.

First point: UML is no silver bullet. It is only as good as the people producing the diagrams, and the people reading the diagrams. If the diagrams are produced by someone who doesn't understand the problem, how can they specify how to solve the problem? And, if they need to be specified to the implementation level, what does that say about your developers? UML works better when used in line with Brook's original hypothesis, that software should be iteratively grown. Build the parts that you can understand, and add (and rebuild) new parts once you have the framework done.

Second point: UML is usually done to death. It's similar to designing a house down to the cut lengths of each board. The additional time and effort in designing to that level is lost when an error is made. However, the error won't be determined until elaboration or construction. So what's the point in trying to design the interaction between all the components, none of which exist yet? UML should only be created to describe the problem to be solved to the level that a developer can understand it and ask questions. Using it to describe the entire application creates a waterfall model, instead of continually refining the model as the application evolves.

On Software and Reluctance to Change

Even in a large, professional, closed-source development office, open source software is held in high regard by software developers. This is countered by management's distaste for it on the grounds that "We have no one to hold accountable if it fails." But why does open source have this (well earned) reputation?

Open source, is even more evolutionary than closed source. Closed source has the advantage of being developed by a paid staff. Open source developers have a much more free range of choice of related projects to support, and the very few that are well organized, well planned, and well executed will survive. Any body can start a new web server project, but very very few will be better than Apache. In an environment without such direct competition for developer resources, a closed source solution can flounder on for years, and the developers may not even know that there is a better way! Think of it like those fish that have evolved to live in caves without daylight. Those fish are the proverbial "big fish in a little pond." But put them out in the sunlight and they'd be killed! But they do fill their niche quite well.

Open source has to have the "Wow" factor. As an outgrowth of the first point, no developer would want to work maintenance on an end-of-life project if they didn't have to. But closed source doesn't necessarily have that constraint. By tying the customer into a set of technologies, the closed source project makes changing from that vendor that much more difficult. Especially in this era of the DMCA, trying to figure out what a vendor did with your data may end up in court! There is some of that in the open source world, but once you can see the source, reverse engineering the data becomes that much easier.

Open source has a long history of being a "hobby." This is the battleship mentality of large, closed source software developments. What they fail to realize is that all those CMMI certifications don't have any correlation to producing a stable, complete product. That those hobby programmers have to have more strict controls over feature development, release schedules, etc. By its nature, open source development depends on a central core of "committers" to control all the distributed effort. Getting that help to understand its job quickly and to perform it to specification is absolutely critical to the success of the project. All the development processes are driven by that point. So being able to reassign a task to anyone who wants to work it must be able to be done with a minimum of effort by the developer and the committers.

If closed source is like a super computer, capable of mind-boggling levels of effort, than open source has the capability to be like Seti@Home, capable of performing to much higher levels of performance than ever imagined!