Geeks and non-geeks alike should do their research when buying electronic devices to make sure they can actually do what they want, and don’t have unacceptable attributes. In this post I’ll give some examples, and some helpful guidelines.
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. Read on…
As a creative person (and as a geek), when building something (software or hardware), I often say to myself “For just a little more time and/or effort, I can add this cool feature.” There are many good reasons why this is a bad idea. I would like to lead with the reason that has caused my blog to be stagnant for months, which is that doing more than you have to gets in the way of actually finishing. An artist I almost knew once said “The hard part about painting, is not the painting, but knowing when to stop.”
Since my last post, I’ve started about six posts that I never finished because I just wanted to add this one last point, or tweak that paragraph one more time. The result was no visible work output, which is inexcusable for an Agilista. Read on…
I’ve been using Linux/UNIX for about 20 years. I am also Assistant Director of the Boston Linux and UNIX Group, and have contributed to several open source products. In general, I find open source software more flexible, more transparent (no security through obscurity), and more focused on what’s needed instead of what marketing says would be cool. I like that open source software is usually developed modularly, with separate components each doing what they do well, each designed to be combined with other component, each with its inputs and outputs documented for fitting Tab A into Slot B. Open source’s community support model (with a sufficiently large community) is often far superior to calling tech support. All that said, I still believe very strongly in “the right tool for the job”. Sometimes open source is not the answer.
Just like commercial software, it’s important to evaluate not only how well the software suits your need, but the “health” of the product and its creators. Just because it’s still available doesn’t mean it’s still supported, updated, and in common use. That may not be a deal-breaker for you, but it does need to be factored in to the decision.
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.