There’s no single right way to develop detailed specifications, just as there’s no single right programming language for every application. Different projects demand different techniques. Requirements managers need a mix of skills to adapt to whatever circumstances they’re working in.

The team’s development process defines who does what, when, and how. Waterfall – activities proceed through a fixed sequence, each step depending on the previous one. Spiral – starts with risk-driven prototypes, then follows a structured waterfall-like process. Iterative – a hybrid that decouples lifecycle phases from the activities within each phase. Whichever model you choose, build at least one early prototype to get customer feedback before committing to a full implementation.

Some people believe the best way to estimate a project is to produce detailed requirements and design documents for every feature before writing a line of code. It sounds professional. It sounds thorough. In practice, it usually turns out to be wrong. Requirements change. Priorities shift. The detailed estimate you spent weeks producing becomes irrelevant halfway through the project. That effort becomes wasted inventory – time and resources that could have been spent building something useful instead. ...

In many projects, in order to provide a reasonable probability of success, it will be necessary to reduce the scope by as much as a factor of two. I’ve learned this the hard way. Every project starts with an ambitious list of features and an optimistic timeline. Reality intervenes quickly – resources are tighter than expected, technical problems emerge, and deadlines don’t move. Cutting scope feels like failure. It’s the difference between shipping something that works and shipping nothing at all.

Every piece of software I’ve developed elicits the same two reactions when users see it for the first time: First: “Wow, this is cool. We can really use this.” Then, immediately: “Yes, but… now that I see it, what about this? Wouldn’t it be nice if…? Whatever happened to…?” The “Yes, But” syndrome is universal. It comes from the nature of software as something intangible – until users see it, they can’t fully articulate what they need. Seeing the implementation triggers new ideas, new concerns, new requirements that weren’t visible before. ...

Software development is a complex and collaborative process that requires effective teamwork and communication. However, many software teams struggle with productivity issues and fail to deliver high-quality products on time and within budget. In this post, I will discuss why team productivity is more important than individual productivity, and how you can improve your software team’s performance by applying some proven strategies and best practices. The Importance of Team Productivity According to Boehm, the COCOMO cost estimation model shows that the capability of the team has the greatest impact on software production. This means that the quality and efficiency of the software product depend largely on how well the team works together. Davis agrees with this conclusion and states that “optimising the productivity of all individuals does not necessarily result in optimising the productivity of the team”. In other words, having a team of highly skilled and productive individuals does not guarantee a successful software project. There are other factors that affect team productivity, such as communication, coordination, collaboration, motivation, and trust. ...

Steve Jobs unveiled the iPad yesterday. A tablet. Bigger than a phone, smaller than a laptop. No keyboard, no trackpad, no USB ports worth mentioning. The internet is already divided. Some call it a giant iPhone. Others call it a toy. A few are excited. I don’t have one yet, but the idea of a device that’s comfortable to hold for reading, browsing, and watching videos while on the couch appeals to me. It fills a gap that neither phones nor laptops really cover. ...

Every problem contains a hidden opportunity. In IT especially – one person’s challenge is another person’s chance to build something better.

Use the -p flag with cp to preserve file permissions: cp -p /aaa/bbb /ccc/ddd

My first Typo3 extension. It’s a front-end plugin that displays a customised Google search engine on your site, using Ajax with tabs for different result types – no page reload needed. You can download it from the Typo3 Forge (link no longer available). The SVN repository was at svn.typo3.org/TYPO3v4/Extensions/ajax_google_search.