What are you going to do?

📖 2 minute read

One of my longtime favorite software gurus, Larry Constantine, gave a keynote presentation at Software Development 2001 conference in San Jose earlier this year. Here is the last slide from his talk:

  • If you don't know what you're going to do before you do it, you don't know what you're doing.
  • If you spend all your time figuring out what you're doing, you're doing nothing. I agree. Feel free to insert planning or design instead of figuring out in the above statement. In an article posted also on foruse.com entitled Process Agility and Software Usability Constantine makes a point that I don't entirely agree with:

Perhaps the biggest selling point of the agile processes is their weight—or lack thereof. There is simply far less to them than to the leading heavyweights, which means potentially less to learn and master. That does not mean that agile processes are easy, any more than it means that agile process can substitute for programming skills and developmental discipline—but it does mean that there is less to explain about the processes themselves.

Larry Constantine

I think that learning the process is a small fraction of effort, almost negligible, by comparison to learning all the other skills that a software engineer needs to know to perform his or her job well. So far all people that I talked to who were good at design, or requirements, or user interface design, or any of the other skills required to create great programs, had already created for themselves a process that closely resembled one of the "published" processes.

Later, in the same article he makes another interesting point. He is in full agreement with Barry Boehm on the most important factor that determines the outcome of a software project: the quality of the people.

All of the agile methods put a premium on having premium people. They work best, if at all, with first-rate, versatile, disciplined developers who are highly-skilled and highly motivated. Not only do you need skilled and speedy developers, but you need ones of exceptional discipline willing to work hell-bent-for-leather with someone sitting beside them watching every move.

Larry Constantine

This brings us back full circle to the same issue that many of you already heard me talk about: How do you become and then continue to be that premium developer? We'll leave that topic for later.