David Bock

Surviving Middle Management

Most good developers eventually have the opportunity to be managers. Whether they call you the “project manager”, “Technical Lead”, “Lead Developer”, or some other classic middle-management title, you become the 'goto' guy between management and developers. You're the guy who is expected to keep the project in-line, track a schedule, and occasionally answer the question “How's it going?“, and perhaps still contribute at a technical level. So how do you do that?

Intermediate Maven

Maven is a build tool that does a lot, demos well, and leaves the build maintainers managing what seems like unbridled complexity. It doesn't have to be that way - Maven is driven by some strong 'build process methodology', and that complexity can become manageable by wrapping your head around it. Furthermore, you can migrate to Maven 'piecemeal', by mapping your existing ant build to the Maven Lifecycle and calling your existing Ant tasks - you can decide to sip the Maven kool-aid.

Ideally, a build tool should be so simple and approachable that it fades into the project background and allows anyone to maintain it. Unfortunately, Maven's power comes at the expense of this ideal - Maven's philosophy is more like “the build process is so important that the people maintaining it should be steeped in the ways of Maven”. This talk will give you the exposure you need without elevating The Maven Way to a religion.

Maintaining Project Integrity with JDepend, Macker, PMD, Maven, and other open source tools

How many times have you started a new project only to find that several months into it, you have a big ball of code you have to plod through to try to get anything done? How many times have you been the ?new guy? on an established project where it seems like the code grew more like weeds and brambles than a well-tended garden? With a few good structural guidelines and several tools to help analyze the code, we can keep our project from turning into that big ball of mud, and we can salvage a project that is already headed down that path.

Software Metrics and the Great Pyramid of Giza

Most software engineers hate metrics… Why? Because we know the work we do is hard to quantify – any measurement of 'software engineering' is like trying to tell how tall someone is by how much they weigh… There may be some correlation, but there is so much deviation as to make the answer practically meaningless. As a result, we often see metrics used to justify improper conclusions. There are plenty of good metrics though, and plenty of ways to use them effectively.