EclEmma

It's been a few months since I last examined EclEmma, the Eclipse code coverage plugin using Emma. Since my first post, there's been a steady trickle of interested parties passing through, which has reminded me to see how things are going.

It's always nice to see an active project, and EclEmma does not disappoint. Since I downloaded 1.0.0, there have been two releases, 1.1.0 and 1.2.0. As is suitable for minor-version numbers, these releases don't include groundbreaking new functionality, but they do include some minor useful additions, such as updated documentation, and, most importantly, one of the features I suggested: "SF #1664476: Filtering option for unused types in the coverage view as proposed by Geoffrey Wiseman".

For more information, check out the EclEmma Change Log or, better still, download EclEmma and try it out for yourself. You won't regret it.

Desired Traits for a Software Executive

After working with a few technology executives, I've formed a few opinions about what traits are desired.

An Understanding of Software
I've built software at a lot of companies. When the executive level of the company is dominated by executives who don't understand software, the net result is that the company doesn't understand how to build software.

This has a number of potential side effects:

• Unable to Make Tradeoffs: The business is unable to make appropriate decisions in the tradeoffs that are a daily part of building software. Is this release date more important than minor quality issues? Is this blocking defect more important than your scheduled release? Is fixing this issue you've discovered a higher priority than feature X?
• Management by Star Trek: Management decisions are made by people who think that Star Trek is a good model for technology management. "The features you've asked for will take thirty days to build." "Well, you've got ten days!"
• Software is Predictable: The business believes that developing software is a mechanistic, predictable task, and does not react well to the inevitable, that requirements are not clear, that implementation sometimes brings up issues that weren't clear in advance, that we mave to make the kinds of tradeoffs described above.
  
• Emphasis on the Visible: The business puts more emphasis on the visible aspects of software than the invisible ones. "You're not done? But I was playing with the prototype a month ago! What's taking so long?"
  

These kinds of problems are not unique to companies that don't have development-savvy executives, but they're far more common.

A Hands-Off Approach
Of course, having development-savvy executives has its own set of concerns. An executive who has been involved in software development can have trouble keeping his or her hands off the process now that they've moved on up.

This can lead to:

• Micromanagement: Having been involved in the detailed decisions of building software in the past, an executive may want to continue that involvement, even though he or she doesn't have the time to be involved day by day and stay in touch with all the information that leads to those decisions. This can result in what feels like arbitary decisions being made seemingly at random.
  
• Technology Zealotry: Technologists often have favorite technologies. Some have difficulty separating their preferences from merit. When those technologists join the executive, they may try and influence or override technology decisions arbitrarily.
  
• Leading by Design: It's not uncommon for more senior members of a development team to be more involved in the architecture and design of a software platform than junior members. This means that someone who has moved up through software development to executive may be used to leading software teams through architecture and design metaphors. Unfortunately, like micromanagement, this may be done without the time and detailed understanding that project team members have to dedicate to this task, resulting in poor design decisions.
  

These problems are more informed than the problems created by executives that don't understand software, but can be just as damaging.

So, in a technology executive, I'm looking for someone who knows how to code, but is willing not to code.

Do your company's executive team understand software? What traits have you found desirable?

Definition: Log4J Ignores Throwable

Our operations team wanted to strip the Throwable from the log output of a particular log or, alternately, remove the line breaks from said Throwable.

After a half-afternoon of toying, I was able to get it done reasonably easily by extending PatternLayout, adding a PatternConverter, and a few other things.

Of particular note is this: the definition of ignoresThrowable() could be a little more clear. When a Layout indicates that it ignores the Throwable, as does PatternLayout, what it really means is that Log4J should print it out after the Layout's job is done.

Accordingly, if you want to NOT print the Throwable at all, you should indicate that your Layout does not ignore the Throwable (so that Log4J won't print it) and then make sure that your Layout class doesn't print it either.

It's minor, but since this was mildly confusing to me on the first pass, I thought I'd share, so that the next person who Googles the subject can peruse this posting before digging any further.

Patience - Attention Bandwidth Will Return

If any of you are following regularly, and I'd like to believe that some of you are, so please don't disillusion me, I'll be back to a regular schedule in another week or so -- at the moment, I've got limited time and attention for feeds, and development because I'm busy rewiring and drywalling two halls, a stairwell, and the living room.

On those rare occasions that I stop renovating and get on the laptop, I'm giving a lot of my remaining attention to catching up on email and getting my relationship with InfoQ kickstarted; I'm going to be contributing regularly to the Java and Agile news.

I'll be back at work, and in a development mindset, on April 16th. If the renovation goes well, I may be back 'in form' before then, but I'm not making any promises.