It’s Never Too Early to Reflect

It’s been an interesting week for blog posts:

1. The folks at Scout just threw away three months of development work, and improved their product by doing. The takeaway lesson is that you should continually ask yourself, “Is the thing I’m writing essential to satisfying the pressing needs of a particular user?”  If the answer is no, put it aside and work on something that is.
2. Martin Fowler (author of Refactoring and many other must-read books) has an interesting post about technical debt; David Humphrey has an equally interesting reply. No matter how careful you are, stuff builds up in any project that eventually has to be cleaned away. The real challenge is figuring out what it is, and when it’s worth tackling.
3. Elmcity’s Jory Graham wrote about how students use chat, email, Twitter, and Facebook updates obsessively for play, but fall silent (or nearly so) when asked to do so for work. Ironically, only two of the 46 students taking part this fall have replied—we’d welcome more of your thoughts.
4. That said, the MarkUs team is talking up a storm: what they’re learning from having real users, a design for simple grade entry (blogs are great for design discussions), and more.
5. Mike Gunderloy updated his description of the tools he uses for development, sparking a flurry of replies (1, 2, 3, 4, 5, 6, 7, 8, 9, and counting). Later this term, I may ask students in these projects (and their mentors) to post theirs as well.
6. “In my 30-year working career, I am struggling to recall a time where I have seen a supplier so slow to react to a catastrophic system failure such as this and so unwilling to accept responsibility and apologise to its client and its client’s customers.” That’s the head of Air New Zealand talking about IBM; one of your goals as a developer is to never, ever be the reason a customer says something like that about your employer.