Today’s lesson for hardware people, software people, architects, and mad scientists is brought to you by Ray Bradbury in the form of a short story called There Will Come Soft Rains. I recommend you follow this link and read a copy of the story, as it’s only a few pages long, and well done (but I already said it was Ray Bradbury, didn’t I?). The story, written in 1950, takes place in 2026 in a very modern, fully automated house, with all sorts of computers keeping its occupants fed, cleaned, entertained, and on schedule for work, school, and play.
Only there are no more occupants. Because there was a nuclear war, and they’re all ashes. The house (the last house standing), in it’s quite-less-than-infinite wisdom, has not caught on to this. So it prepares eggs and pancakes for breakfast, and provides entertainment in the nursery, and defends itself from the few birds and animals that may approach it, and fleets of mechanical robots diligently clean up any dirt that gets in the house and dispose of the uneaten food. In short, this system has insufficient connection to the world it interfaces with, and too few checks on expected responses, to know that something is horribly wrong.
Read on…
I have heard several talks and attended several presentations both comparing Scrum and Kanban and explaining how they can be used together. I came across this article, which talks about this article (I list both because the commenting article brings up good points, too). So why am I adding yet another level of indirection to this chain? Because an awful lot of people understand past the surface and the buzzwords of the various flavors of Agile/Lean, and that leads to confusion, unmet expectations, and failed projects. The most important point of these articles is that Scrum and Kanban are not interchangeable techniques. They differ greatly in scope and goal. That’s why they bring up the metaphor of choosing between a knife and fork.
Read on…
One of the frustrations of managing software development is that different people have a different idea of what “Done” means. It can range from “It compiles and it’s checked in”, to “It compiles, and all the unit tests pass, and new unit tests were added for the new functionality, and the documentation was updated, as was the issue tracking system, and the QA guys signed off on it”. This is especially a problem with Agile development, because so much rides on a common understanding of the state of the software.
Alixx Skevington recently posted an article in the Agilistas group on LinkedIn called My Manifesto of done. It’s an interesting read, and a good start. He’s flagged it as a draft, so I don’t say that as a criticism. I know I’m going to follow that discussion (I’ve already contributed to it). Hopefully it will turn into something that companies can point a finger at and say “Do this”.
Generally speaking, I hate frameworks. Most frameworks I’ve met fall into one or more of these camps:
- Frameworks so lightweight that they’re not worth the hassle of using them. These frameworks can be useful when you need some functionality that you don’t want to learn in detail how to do. This is almost never the case for me, because I like fully understanding any technologies I rely upon. That’s why at Aptima I wrote my own AJAX JavaScript library. It was something like 50 lines of code, worked flawlessly, and worked exactly as I wanted it to.
- Frameworks so heavy the work to utilize them approaches the work of rolling your own. This often happens with frameworks that start out simple and are expanded to encompass too much functionality outside of the original scope.
- Frameworks that are staunchly inflexible in how they are used and how they work. Using a software tool to make your life easier should not like implementing an ERP system. This often happens when when the framework was designed for a specific purpose then released as a separate product. See The Cathedral And The Bazaar.
- Frameworks that are completely opaque or have an unreasonable learning curve. Most meaningful operations in software have some sort of side effect you need to be aware of. Insufficient documentation and software that does not follow the mantra of the Principle Of Least Astonishment can make diagnosing problems a nightmare.
I’m currently working on my knowledge and skills with Spring and Hibernate. They continue to fail to suck. I was very surprised how easy they were to implement, how much they’re for me, and how flexible they are. Spring is a framework that specializes in (among other things) inversion of control to promote decoupling and testability, and Hibernate is an object relationship mapper that eases the burden of persisting entities in a database. There are many good tutorials on the Intertubes, but I’ve been working my way through the book Spring Recipes, which covers both technologies very well.
Read on…
Those who know me will back me up on this; I evaluate things fairly. You will never hear me say $FOO is clearly superior than anything else, and there’s no reason for anyone to use anything else. That includes Linux and Linux distros. I calls them as I sees them, and I do not feel that Linux is always better in every situation for every user, nor is one distribution/brand of Linux clearly the best for all situations. And I’ve been using Linux since Red Hat 4.2 in 1997 (I still have the disks).
I recently installed Ubuntu Karmic (9.10), waiting a few months after release as I usually do so the major bugs are already fixed, and ran into many more problems than I expected. I find this unfortunate, because one of the main reasons I switched from Fedora to Ubuntu is no longer valid. Some of this post is about this release, and some is about the state of Linux in general.
Read on…
Some think Agile is all seat-of-your-pants. That’s not true at all. Agile requires knowing where you are right now and what you need to do in the near future; it just doesn’t put a lot of faith in guesses where you’ll be 8 months from now.
The various forms of Agile all contain a set of practices to follow and others to stay away from, each with their strengths and weaknesses. Successful implementation of Agile requires selecting and implementing practices that complement and support each other, covering all required needs without duplication (which is where a good deal of the efficiency comes in). It’s bad enough if you pick a set of practices that don’t support each other, but it’s much worse to chose the right practices but not implement them right. That’s because it can create a false sense of security. Read on…