Archive

Archive for the ‘sdlc’ Category

XP QoW: Responsibility is accepted, not given

March 26th, 2008

The third in my series of quotes from Extreme Programming Explained: Embrace Change by Kent Beck. Once a week I post a quote from XP that I think is really important to consider when developing software. This is from the end of Chapter 8:

Accepted Responsibility-No single action takes the life out of a team or a person more than being told what to do, especially if the job is clearly impossible. Primate dominance displays work only so long in getting people to act like they are going along. Along the way, a person told what to do will find a thousand ways of expressing their frustration, most of the them to the detriment of the team and many of them to the detriment on the person.

The alternative is that responsibility be accepted, not given. This does not mean that you always do exactly what you feel like doing. You are part of a team, and if the team comes to the conclusion that a certain task needs doing, someone will choose to do it, no matter how odious.”

There are two key things to listen to in this excerpt. First always work with your direct reports to define, estimate and plan their work. If they have helped craft the goal they will feel much more ownership toward completing on-time and at high quality. Secondly, if you have buy-in from everyone on the team then they will want to do everything needed to complete the project.

The job of the manager is to pick the destination and make sure everyone is rowing towards. Everything else is up to the team.

Looks for more XP Quotes of the Week to be forthcoming.

Past quotes:

sdlc

XP QoW: Assume Simplicity

March 12th, 2008

The second in my series of quotes from Extreme Programming Explained: Embrace Change by Kent Beck. Once a week I post a quote from XP that I think is really important to consider when developing software. This is from the second page of Chapter 8:

Assume simplicity-Treat every problem as if it can be solved with ridiculous simplicity. The time you save on the 98% of problems for which this is true will give you ridiculous resources to apply to the other 2%. In many ways, this is the hardest principle for programmers to swallow. We are traditionally told to plan for the future, to design for reuse. Instead, XP says to do a  good job (tests, refactoring, communication) of solving today’s job today and trust your ability to add complexity in the future where you need it. The economics of software favor this approach.”

Two guys built Twitter in two weeks.

Looks for more XP Quotes of the Week to be forthcoming.

Past quotes:

books, sdlc

XP QoW: The Customers get to Pick 3

March 5th, 2008

I recently got around to reading Extreme Programming Explained: Embrace Change by Kent Beck. My wife had gotten it for me a year or two ago when she read a recommendation on Bram Cohen’s blog.  Bram is most notable for creating BitTorrent he recommedned the XP book, Peopleware and Non-Manipulative Selling.

Since it’s publishing in 2000 this book has caused a good amount of change in the software industry in the take of agile processes and adding things like Continuous Integration to traditional waterfall projects.

Once a week I’m going to post a quote from XP that I think is really important to consider when developing software.  The first is from the beginning of Chapter 4:

“…there are four variables in software development”

  • Cost
  • Time
  • Quality
  • Scope

 The way the software development game is played in this model is that external forces (customers, managers) get to pick the values of any three of the variables.  The development team gets to pick the resultant value of the fourth variable.”

Every project and development manager should read this full chapter before planning a project.  it’s only 5 pages so it only takes a few minutes.

Looks for more XP Quotes of the Week to be forthcoming.

books, sdlc

Closing a Few Doors: Software Requirements Gathering

February 27th, 2008

Wow, the parallels in Dr. Ariely new book “Predictably Irrational” to the Software Requirments Gathering process are unintentional but powerful.

“Xiang Yu was a Chinese general in the third century B.C. who took his troops across the Yangtze River into enemy territory and performed an experiment in decision making. He crushed his troops’ cooking pots and burned their ships.

He explained this was to focus them on moving forward — a motivational speech that was not appreciated by many of the soldiers watching their retreat option go up in flames. But General Xiang Yu would be vindicated, both on the battlefield and in the annals of social science research.

He is one of the role models in Dan Ariely’s new book, “Predictably Irrational,” an entertaining look at human foibles like the penchant for keeping too many options open. General Xiang Yu was a rare exception to the norm, a warrior who conquered by being unpredictably rational.

Most people can’t make such a painful choice, not even the students at a bastion of rationality like the Massachusetts Institute of Technology, where Dr. Ariely is a professor of behavioral economics. In a series of experiments, hundreds of students could not bear to let their options vanish, even though it was obviously a dumb strategy (and they weren’t even asked to burn anything).

The experiments involved a game that eliminated the excuses we usually have for refusing to let go.. In the real world, we can always tell ourselves that it’s good to keep options open.

You don’t even know how a camera’s burst-mode flash works, but you persuade yourself to pay for the extra feature just in case. You no longer have anything in common with someone who keeps calling you, but you hate to just zap the relationship.”

How many of us have fought business analysts who want ‘everything configurable’ and to deploy ‘every feature’? Frankly, I can’t think of any bigger timesink for software teams these days.

See the full article and NYT review at: The Advantages of Closing a Few Doors – New York Times

sdlc