What is Design?
I see many discussions get heated or go in circles when the topic is “design.” In the field of software development, what is design? Read More
I see many discussions get heated or go in circles when the topic is “design.” In the field of software development, what is design? Read More
Oops! The whole problem started when I wanted to install a new program on the “entertainment computer” that’s connected to the TV. The existing version of Ubuntu was no longer supported, so I started what I thought would be a simple upgrade. Oops, it deleted the entire /var directory, including the contents of the second drive mounted there. That drive contained all of our photos and music. Not a problem, I thought. It’s all backed up nightly onto a USB drive. It’s just a bit of bother to copy all of that over the USB interface.
Oops! There are no photos beyond last March. I felt sick to my stomach. That’s a lot of family memories to evaporated. Whew! The program we’ve been using to download the cameras also makes a backup copy local to the machine used to download. I’ve got all the pictures back on the photo server, and now just have to sort them into directories again.
But first, I need to fix the backup script. Why didn’t it warn me when it started to fail? Read More
An article in USA Today (December 12, 2012) about highway projects in New York has the sub-head, “Design errors, planning lapses drove up costs more than 14%.” Among the things listed that “drove up costs” are
It’s true that no one likes for costs to exceed estimates, Read More
Yesterday, Bob Payne published one of our informal Tips and Advice discussions on the Agile Toolkit. Check out our Test Driven Development podcast and let me know what you think.
Yesterday, Yves Hanoulle published his interview of me as part of his Who Is series. It was a good opportunity for a little introspection about myself and my career. Read More
I hope this will be done by then.
These are sad and scary words to me. When I hear them in the context of a software development project, I associate them with a project unlikely to meet expectations. Further, it’s likely that there is no good indicator of what can be delivered when. With no hard evidence to tell them what’s possible, and to judge the effects of changes they try, people fall back on a strategy of hope. They no longer feel in control of the situation.
We’ve done our part.
This signals the underlying hopelessness. When you can’t make things come out the way you want, when you can’t even predict how they will come out, one natural response is to give up. Often the cultural expectations don’t allow saying “this project is in trouble.” The person who does so is the person who will attract all the scrutiny. Without the clear data to back up the perception of trouble, why stick your neck out? Others should be noticing the same thing; let them call attention to it. And when things don’t work out as “hoped,” if weve “done our part,” then someone else will get the blame.
You can’t solve a problem that no one wants to see. Instead, we’ve found an acceptable way to fail.
When we write code, we’re often thinking about the short term. We need this code to function correctly so we can deliver within our immediate deadlines. I’ve found it important to also think of the long term. Sooner or later, we might encounter our own code, again.
I spent a chunk of my career where I often worked solo on projects that might get enhanced every year or two. This taught me a lot about the importance of code readability and what sort of things helped me quickly understand and avoid overlooking important considerations. I’ve also worked on a lot of legacy code bases, so I’m well aware of the pain and problems created by code that’s not readable, or is not organized in a helpful manner. Read More
Most of my recent writing has not yet been published. That, and work on the upcoming AgileDC Conference and Agile India beyond that, have meant relatively little output on my blog. I apologize for that.
I’d like to share with you an interview conducted by Bill Fox for his 5 Minutes to Process Improvement Success project. My interview, “Measure Progress in a Way that’s Visible and Reliable,” is found on page 69 of the PDF. You’ll also find interesting interviews with Karen Base, Kevin Schaaff, Hillel Glazer, Scott Ambler, Neil Potter, Bob Payne, Mike Bonamassa, Mario Hyland, Jeff Dalton, Paul E. McMahon, Karl Wiegers, Mary Lynn Penn, Ally Gill, Alan Shalloway, and Tom Cagley. And there are more to come in the future.
If you coach Agile teams, if you mentor your peers in better software development practices and processes, or if you are just learning to do these things, the Agile India Coaching and Mentoring stage needs your help. Please propose sessions about your work and your experiences.
Many organizations segregate their programmers and testers in order to achieve independent validation of requirements. If the system is tested according to an independent interpretation of the requirements than used for implementation, then errors in those interpretations may be detected.
This course of action is obviously prudent when the requirements are handed down to the development organization in the form of a document. Read More