Is negativism between developers the norm? Probably not, but it’s common. Do developers ever compliment each other? Yes, but it sometimes seems rare. When I step back, it does in fact seem that there is sometimes a noticeable wealth of negativism and a noticeable lack of complimenting. The nature of software and its developers may contribute. But we can overcome our challenges.
There is an epic balancing act in software today, fought between customization and convention. When to build, when to buy? When to create new solutions or reuse those already created? What are the pros and cons to either? I don’t think that there is a quick answer that is going to always be true for any of these questions? Each situation brings with it too many diverse aspects. But, here are some of my observations.
Barriers are created all the time on software projects (by organization layout, role definition, project management, or indiscriminately) that keep developer knowledge separate. Sometimes these barriers are referred to as silos. We can create better teams and products for our organizations if we can break down these silos – or if particularly scrappy, blow them up.
In Agile software development, an iteration is a time period of work, where the full software dev cycle is completed. Iterations are iterative, done over and over again. And yet, many project teams find making the most of each iteration challenging. On my current project, I feel like an important part of making each iteration solid and progressive is the iteration planning, which I feel is done very well. Iteration planning, done well, relies upon project management and each team member. Here are some of my observations.
Recently, I had the opportunity to look at a set of user stories on an upcoming project and apply a high level estimate to each. These estimates were going to provide a starting point for determining project timeline and schedule. Every time I’m presented with a request for estimation, I shiver a little because I’m so bad at it. As I understand it, I’m not alone in this weakness. I have found, however, that the more requirements that can be defined and the more detail that can be described for each, the more accurate a timeline can be established.