Real developers write code — not status reports.
I Need It
There are typically 2 reasons for needing status reports: 1) collaboration and 2) monitoring.
Agile shops recommend status reports for the first reason. Software development is a team sport. Rarely do individuals work in a vacuum, so regular status is important to address dependencies, remove blocks, and ensure folks don’t step on each other’s toes. The manager may collect reports for logistical reasons, but the reports aren’t for managers — they are for the team.
Monitoring is more common in consulting arrangements. Work is being done on someone else’s behalf and that person wants to monitor the activities. Very simply they want to ensure they getting what they are paying for. Every once in a while you read about dysfunctional uses of status reports. This “use case” is commonly the scenario where that’s found. The reason is that people often don’t care until there is a problem. Then the reports are reviewed to help understand where things went wrong.
Read More
This is the first post in a series of video interviews with software development industry notables.
I recently had a chance to sit down with Scott Davis and discuss where he sees our industry going this year. He also has some sound advice for any ambitious developer planning their next career move. And for those of you that don’t know Scott, he is a fellow No Fluff, Just Stuff speaker and author of several books including Groovy Recipes and GIS for Web Developers.
Read More
Users of our service should now notice that something is different. With the latest release, we've dropped Scalable Vector Graphics (SVG) as our default format for charts for PNG. The marks the end of an era of our unwavering support for this bleeding edge technology. Some times we take chances using certain technologies and those chances work out -- it saddens me that this chance didn't have the envisioned return.
Read More
J. B. Rainsberger has a great blog entry titled Should We Measure Velocity on the importance of knowing where your team spends their time. He says knowing your history is more important than estimating new features.
It’s difficult to know where your development team is headed. Even with a perfect knowledge of how the team members work and how long it takes them to complete a feature, the specification often changes in the middle of a project. I’ve never finished a project with the original set of requirements.
Read More
Continued from this post...
The execution section of Fowler's book is about day-to-day activity—how you're delivering value to yourself, your team and your projects. The emphasis here should be at the team and project level. Fowler suggests that sometimes we get wrapped up in ourselves and expect everything to revolve around us, which can cause our overall performance to decline. Instead we should be focusing on the quality of our job and deliverable—daily. Loving what we do, even the maintenance or drudge work, and truly embracing our profession. What a concept!
Other good points he makes relate to not burning ourselves out with overtime and learning to say "No" more often, and learning how to fail. Failure implies that we're stretching ourselves and taking risk—that we're trying to do things outside of our comfort zone and that with each failure comes a later, more experienced success.
Read More
