Project Management

Contest: Craig Larman - An Agile Evangelist

This is the second of a series of contest entires. Voting begins on Friday 08 September.

After some very serious pondering I have come to the conclusion that the person who has had the most profound impact on me has to be Craig Larman. Although there are of course several movers and shakers that have influenced me, Mr. Larman is the one that really has made me think differently about software development.

Craig Larman is the author of "Agile and Iterative Development: A Manager's Guide". At first the book title felt repelling since it was directed at managers and I certainly am not one. Fortunately for me I read the book - I devoured it in a few nights. The concepts of Agile software development seemed so perfectly sane and logical that I was shocked that I hadn't thought of them before. This image of a this-is-for-your-own-good kind of down-to-earth mentality was further enforced when I got to hear Craig speak at the second ever Agile Finland seminar.

Craig Larman has permanently shifted my brainwaves by such a degree that I will not - without influential coercion - go back to the Dark Age of Software Development from which I was once freed.

Vacations, Adaptation, and Software Project Success

If we managed software projects the way we manage vacation trips, the success rate would skyrocket.

When my wife and I planned our last vacation to Seattle, a city I had never visited, we had bunch of unknowns.

Where was the best area to stay? What did we want to see? Was it the best time of year to go? Can we get a good deal? How long should we stay? What are the best places to eat?

Just like on a new software project, there was no way to know any of these things for sure, even though we read a few guide books, and talked to a few friends who had been there a few years ago.

Why Bug Fixing Can Be Hazardous To Your Project

Stop fixing that bug right now! You could be putting your project at risk without even knowing it.

When I first started developing software over 15 years ago, I thought that bugs were evil, and should never appear in any software. It was a matter of personal honor, integrity, and pride to eliminate any bugs.

Only one problem with that approach. There is an opportunity cost to every bug you fix. And there is a risk factor as well.

Just Say No...To Your Customers?

"Can you add a Whizzy-Woo in the next release? It should be easy since you've already got a Doo-Dad-Adapter."

Ever get one of these requests from a customer? If you're trying to build a clean, usable, and effective application, the answer should always be NO initially.

But isn't the customer always right? Not about features.

Versioning - The Next Big Thing

In the web development world, anyways. So, in the grand scheme of things, maybe not a huge deal to anyone else. Versioning is going to be one of the biggest problems and opportunities there is in web development, and it's going to take us at least five years to get it right.

Actually, let me admit up front that five years is a shot in the dark, and optimistic to boot. If people keep hanging out with bondage and discipline languages like Java and C# that are still catching up to language and framework developments from the 90's it'll take us more like ten years. (Attention Lisp Weenies: Yes, I know you solved every problem forty years ago for certain values of "solved" and "problem" while the rest of us were getting work done.) Not only is versioning a difficult technical problem, it will be difficult to educate programmers in what it is, how it works, and why you'll wish you used about a year after you decided it was too much work.

House of Software Development

We've started a software developer's book club at work, and our first book is Code Complete, 2nd ed. by Steve McConnell - probably the highest recommended book on software development today.

Our division is just starting to organize itself from a staff-augmentation focus where we'd help out clients with relatively quick and easy programming solutions to a structured software development focus. It's more of an attitude shift than a job-type shift, really. We aren't going to start selling shrink-wrap, we're just going to start laying down some procedures and standards and a methodology of sorts.

Coincidentally to reading the first chapter which reviews the major aspects of software development and discusses different analogies (including that of building a house), my boss asked me last week to basically define my own role in the new hierarchy, which itself is still being defined daily.

Like nails on a chalkboard

You know the feeling... someone says something in a meeting that just grates on you. You know it's not true and now you have a choice. Do you nuke them, politely point out where they've erred, or do you simply forget it and go on with life? I had the opportunity to review a slew of Project Management books recently and Applied Software Project Management by Andrew Stellman, Jennifer Greene was one of them.

Their phrase "All developers are created equal" grated on me in this way and initially I went with the third route, but when they recently wrote an article for OnLamp titled What Corporate Projects Should Learn from Open Source and then it made Slashdot, I had to respond.

Outsourcing viability, part 2

Last week, I talked about the viability of outsourcing as relating to contrasting pricing models.

One topic I discussed was the difference in price based on geography. I aluded to a worldwide scheme, but I got to thinking more about just the US, which I am most familiar with.

I currently reside in an area where the cost of life is low, relative to other parts of the country. If you look at my house payment vs. the house payment for someone living in a much more metropolitan area, they are paying considerably more.

Process over programs

Software development, at heart, is the discipline of modeling business logic (or il-logic, if you will). The classic steps go something like the following:

  1. Document the existing process, such as an accounting form or communication need between entities
  2. Determine if there are any existing IT system driving the process
  3. Build a prototype or story board a solution, accounting for #1 and #2
  4. Supposing that the prototype solves the problem (or least makes thing better), go ahead and build it using whatever design/code methodology that suits the project.
  5. Deploy the system to production and commit to caring and feeding for it until doomsday or the process needs revision, whichever comes first

While this is a fine way to build software, it isn't a fine way to solve core problems. For that, I suggest we add step 1.5: evaluate the process.

Outsourcing: always viable?

I've been outsourcing a lot of programming work lately, because I have a lot of things I need to get done and not enough people to help me. We've got the money to do it, and I'm of the mindset that investing in our applications will not only make our own workers more productive, but give us some options for selling products which for many years we've only ever used internally.

Some of the work I've farmed out has been Ruby on Rails development, and the rest has been application development from a company where I was familiar with the developers through some of their open source projects.

The experience has been eye opening to me. I've shifted from lead developer on all of our important projects to project manager. That's another story in itself, and it's been a fascinating journey.