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.