David Bock
Northern Virginia Software Symposium
Reston · November 2 - 4, 2012
Principal Consultant, CodeSherpas Inc.
David Bock is a Principal Consultant at CodeSherpas, a company he founded in 2007. Mr. Bock is also the President of the Northern Virginia Java Users Group, the Editor of O'Reilly's OnJava.com website, and a frequent speaker on technology in venues such as the No Fluff Just Stuff Software Symposiums.
In January 2006, Mr. Bock was honored by being awarded the title of Java Champion by a panel of esteemed leaders in the Java Community in a program sponsored by Sun. There are approximately 100 active Java Champions worldwide.
David has also served on several JCP panels, including the Specification of the Java 6 Platform and the upcoming Java Module System.
In addition to his public speaking and training activities, Mr. Bock actively consults as a software engineer, project manager, and team mentor for commercial and government clients.
Presentations
Estimating vs. Guessing - How Agile Teams Estimate Their Work
Estimating is regarded as little little more than 'educated guessing', but so much can hang on the quality of those estimates. With good estimates we can set clear expectations for project delivery, but with bad estimates we can run over schedule and over budget, or worse. We often estimate when we know the least about the work that needs to get done - so how can we make the best of what is potentially a bad situation?
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?
Managing Complexity (The Project Integrity Series)
How many times have you started a new project only to find that several months into it, you have a build process that mysteriously fails, a bunch of 'TODO' and 'FIXME' comments in the source, and problems that come and go because “it works on my machine”? Does your project have a little bit of 'folk wisdom' that isn't well-known, but is necessary to get things done? How easily could you recreate your development environment if you got a new machine today?
Maintaining Source Code Quality (The Project Integrity Series)
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? Have you ever been the 'new guy' on a project where it seems like the code grew more like weeds and brambles than a well-tended garden? With a few good 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.