Since I’m in Boston, we have a lot of snow to deal with this winter. The other day I was clearing snow off my roof with a roof rake, and after about an hour for some reason it started pulling to the left when I pulled straight down. I started to compensate by pulling the roof rake more to the right to compensate, but that didn’t really help much. After finally getting frustrated enough to pull the roof rake down and look at it, I saw that one of the support brackets was no longer screwed to the rake, so the blade was unsupported on that side. That’s why the rake was pulling to the left. Had I looked at the rake as soon as I noticed the problem, I would have saved a lot of frustration, and possible permanent damage to the roof rake. I fee we do the same thing with our software tools a lot.
Very often I’ve seen software where the usual reaction to compilation warnings is to tell the compiler to ignore them. There are times when this is appropriate. My favorite example of this is with Java Generics, where it’s very hard to get around some of the warnings for things that you and I know are perfectly safe. Most of the time, though, compiler warnings are indicating a moderate to serious problem, or at least an area where the program might not be doing what you think it is. Eliminating those warnings is an excellent collaborative activity, because we all have experience with different software issues.
So the next time you feel tempted to “ignore the Check Engine” light, spend some time finding out if there’s a more elegant solution than putting tape over it.
As a Software Engineer and as a geek, I face many tempations. One of them is “I can add this really cool feature while I’m in the code, and it will take hardly any extra time. It won’t impact any of my other work at all”. There are some very good reasons why you shouldn’t do it though, and why it’s an Agile anti-pattern.Continue reading
Agile methodologies, like most flexible yet powerful systems, rely on knowing exactly where things stand. You may not know exactly what’s coming in the future, but you know what you’ve already got, and roughly how close work in process is to done. This is one of the many reasons short iterations are a good idea. Not only do you know on a frequent basis (the end of each iteration) where you stand, but if what was done is acceptable to the stakeholders (and QA) and can really be considered done. The product backlog tells you what needs to be done in the future (based on current knowledge, which may change, and that’s OK) and the iteration backlog tells you what’s done and what needs to be done now. The burndown chart shows how things are going inside the iteration.
I have to admit when I first experienced Adobe Flex, the successor to Adobe Flash for rich internet application development, I thought it was a fragile toy that wasn’t good for much more than pretty moving pictures. At my current day job, I had to not only learn it, but spend about half my time working in it (as opposed to my current favorite language, Java). One thing I’ve learned from the experience is that it wasn’t so much Flex that I had a problem with, as much as Flex Developers. The Flex developers I’ve worked with up until this job came to Flex from being Illustrators, Graphic Artists, or just kinda fell into it. They never learned the art of software development, never learned to appreciate best practices, and never learned to value code quality or readability. But as a long-time Software Engineer, I know you can create bad software in any language. But now I’ve spent about 10 months working in Flex, and feel I can opine fairly.Continue reading
In my last post
, I talked about tools for tracking Agile projects. Whatever too you use, you have to know what to do with the information. It’s not just about the project being ahead or behind schedule, it’s about using the information to improve the software development process and its implementation. One optimization which has been part of many Agile schools from the beginning, back to the Toyota days, is minimizing work in process. In fact, it’s the major focus of Kanban.
Work In Process isn’t just code sitting in your editor. It’s any task that’s not done, done, done. In other words, if it hasn’t made it all the way through your software process, it’s still work in process.
I admit it, I’m a bit of a geek. OK, I am an Alpha Geek. And yes, I sometimes go with the slightly more computerized solution that others might. I just don’t get Agile’s fascination with sticking hundreds of pieces of paper on the wall, though. Agile teams need a mechanism to share knowledge about stories and tasks. They often do this by using whiteboards with sticky notes (so they can be moved) or cork boards with push pins and index cards. There are columns for the stages (waiting, in process, in QA, done done done) and rows for each story. This article shows an example of one.
I talked about it with an Agile coach friend of mine, Nancy Van Schooenderwoert of Lean Agile Partners, and she made a good point that the paper system makes the whole process easier to learn. She also pointed out that all software has limitations, and it’s important to start out with the index cards or sticky notes so you don’t get the impression that any limitations in the software are a limitation in the Agile practices. I get that. But once the team is passed that point, it’s time to use software-based collaborative tools. Why?