Software Best Practices

Workshop Kurt Lewin said, “There is nothing so practical as a good theory.” A gift from pioneering family therapist Virginia Satir is a good theory about how people process change. The Satir Change Model describes the: five major stages of a change; transition between stages; effects each...

DAVID: Ruth, I think we should buy the ABC software to track trouble tickets and issues. RUTH: There is no budget for that. DAVID: But it takes me days to put together the information you want about the state of the product. And without an automated collection mechanism, I think many problems aren’t...

Getting better in software development requires change and change is hard and change is unpleasant. Most of all, it doesn’t seem like we actually change. We talk about change, we start change initiatives, they pay people to teach us new ways, we may even read books, but at the end of the day we seem...

I have recently read a book called “ Change or Die ” by Alan Deutschman that has some good insights on how people change deeply held behavior. I like to share some thoughts inspired from (and some outright lifted from) the book. We spend a lot of time talking about change. We want to become more agile...

Another requirements related idea I like (which I know you already know about) is Tom Gilb's idea of the requirements "landing zone." Some requirements are binary -- the software meets the requirement or it doesn't. But others are "scalar." These are the requirements that...

David, You provide some more good techniques for anticipating changes. Here's how I would summarize them: Component Level Estimating Estimating Best, Worst, Expected Cases Using standard percentages for downstream activities Active risk management to build your contingency Re-Estimating when more...

Hi Jerry, Some good questions! I will do my best to answer... On that project the original estimates were created by breaking down the product into components and then estimating best and worst case effort for code and unit test of each component. My management required a single figure rather than a...

David, My observations is the same as yours -- the high-level requirements are pretty stable. I like your solution of giving the developers the freedom during coding. Of course, your post raises several questions. Are you using this technique on plan-driven projects? If so, how did you account for this...

Change is a very broad term. In my experience the high level requirement (i.e. an online ordering system) is rarely subject to much change. The detail of what has to be delivered changes enormously over time but a lot of this “so called” change is in fact the process of developing a high level requirement...

Change is inevitable on a project. It doesn't matter if you using agile or plan-driven techniques, you must embrace change. Agile embraces change by being very responsive -- they point out that the future is unknown, so they just look to the near term. Plan-driven techniques are used when the customer...