Archive of Software development Articles

Economic pressures are driving most companies in high-developer-salary markets to explore using offshore development teams as part of their approach to developing software. Developing software with a global team presents new challenges as well as new benefits. If you do it right, you can have a more cost-effective team. If you do it wrong, you can have a disaster.

Instead of

Prioritize the present when planning your product. Neglecting the future is almost as bad as over-emphasizing it. The key is to incorporate your plans for the future correctly by making them play second fiddle to the present needs of your market. Serve both today and tomorrow - but prioritize today.

We’ve been promoting use cases as the right way to approach agile requirements, and in a recent article, Alistair Cockburn stresses the importance of use cases. Over the last three years, he has found that teams that avoid use cases consistently run into the same three problems. We defer, of course, to Alistair as the expert. But we’ve been independently promoting this practice too. So today, we get a cookie!

A successful agile team requires someone on the team to act as the voice of the customer, someone to lead the developers, someone to lead quality assurance, and someone to organize, coordinate, and assure execution. For an agile team to succeed in an enterprise ripe with political resistance to agile, someone has to be the “voice of the team” as well.

You can approach this by classically assigning roles and responsibilities - but that isn’t the only way. Agile teams are most effective when they have specializing generalists who can mutably adapt to the immediate needs.

Learning how to write use cases can be tough, but it is simple compared to the balancing act of determining which use cases to write and how to manage the expectations of all the stakeholders that are involved. It can be a difficult balancing act to prioritize use cases to assure that you meet the goals of the business while satisfying the needs of the users.

Netlife Research (company website in Norwegian) has done it again. Their 2008 Bad Usability Calendar is here and it is great. So great that it is hard to pick a favorite. Download it here. 2007 has more great examples.

[Note: This is a short post- just got back from the Velvet Revolver concert at Stubb's. Living in Austin rocks!]

You want your software to be used, not to sit on the shelf. You can’t achieve the ROI of your software if people don’t use it. And you can’t achieve the ROI of your software by forcing people to use it either.  Some will fail to achieve the benefits, and others will delay using it or refuse to use it entirely.  You have to make them want to use it, and you have to design the software for the users who must use it.  Otherwise, you won’t achieve the ROI.

No matter how good your quality process is, you are introducing bugs. This article reviews the places where bugs are introduced in the software development process (from stakeholders to users), and reviews ways to address those bugs.

We’ve written before about several characteristics of well written requirements, and one of those characteristics is testability. Ahamad has written an list of 10 tests of requirements, with an emphasis on assessing the testability of the requirements. The testability of the requirement determines if the resultant product can be tested to determine if it meets the requirement.

A client at a large company with large development teams and a long history of waterfall development made a comment: “The only people who are talking about doing this project in Agile are developers who think it will allow them to avoid responsibility.” My client may have been right (that people were saying that) but the developers who were saying it were wrong. Agile increases responsibility - it doesn’t absolve it.