There's been a few posts over the last couple of months about TechnicalDebt that's raised the question of what kinds of design flaws should or shouldn't be classified as Technical Debt.
Like many geeks I'm into photography. We geeks like photography because it provides the veneer of an artistic endeavor while allowing us to indulge in lots of technical details and spend money on expensive toys. A friend recently asked about my camera buying decisions, a question that prompted me to write them down.
Barack Obama's victory in the 2008 Presidential campaign included a significant contribution from software - particularly using the Internet. But perhaps the most interesting aspect was the interplay between advances in software and developments in the human organization of the campaign.
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
One of the side benefits of speaking at the Google IO conference last month was that I got a new phone - the HTC Magic android phone that Google gave to all attendees. I was actually in the market for changing my phone to something like this, so it came at a good time. Here's my impressions after carrying it around for a month or so.
What's the most common programming language in the world?
ThoughtWorks started using Ruby for production projects in 2006, from then till the end of 2008 we had done 41 ruby projects. In preparation for a talk at QCon I surveyed these projects to examine what lessons we can draw from the experience. I describe our thoughts so far on common questions about Ruby's productivity, speed and maintainability. So far our conclusions are that Ruby is a viable platform that should be seriously considered for many forms of applications - in particular web applications using Ruby on Rails. I also go through some technical lessons, including some thoughts on testing with Active Record.
Recently some of our developers ran into the accusation that with a dynamic language like ruby you use so many dynamic type checks that you end up effectively writing your own type system. So they thought, since we've written a lot of real ruby code - how often do we make dynamic type checks? Michael Schubert gathered up the data.
A couple of weeks ago there was a Ruby conference in San Francisco called GoGaRuCo (Golden Gate Ruby Conference). This conference has grabbed attention due to a talk at which the presenter illustrated a discussion of CouchDB by using sexually suggestive pictures of women. Unsurprisingly the result has been a fair bit of heated, and occasionally offensive, debate.
I use the term lay programmer to mean someone who is programming without thinking themselves as a programmer. Someone who spends a large part of her day working on spreadsheets is doing programming, often very intense programming. Usually however she won't call herself a programmer, nor think of spending much time learning how to program better.
This is my usual DSL intro talk, but done with a twist as I'm talking to a much more DSL-aware crowd than usual. So essentially I twisted into a talk about how I introduce DSLs to people.
My colleague Zack Exley and I talk about the software that was used by the 2008 Obama presidential campaign. An aspect I found particularly interesting was the way in which the software enabled and interacted with the organizational approach to the campaign.
I spent some time recently with one of my favorite ever ThoughtWorks projects. It's a project that started in 1998, using then new J2EE technology. Over the years it's had a fascinating history: starting with EJBs, ripping them out, going offshore to Bangalore, coming back to Chicago. Many people have moved in and out of the project and the project has varied in head-count between 6 and 60. Overall the project has had over 300 staff-years of effort on it and weighs in at around 100 KLOC.
One danger that DSL advocates need to guard against is the notion that first you design a DSL, then people use it. Like any other deice of software, a successful DSL will evolve. This means that scripts written in an earlier version of a DSL may fail when run with a later version.
Should I use a Rules Engine?
With the rise of Distributed Version Control Systems (DVCS) such as git and Mercurial, I've seen more conversations about strategies for branching and merging and how they fit in with Continuous Integration (CI). There's a bit of confusion here, particularly on the practice of feature branching and how it fits in with CI.
One of the classic cases for using a TestDouble is when you call a remote service. Remote services are usually slow and often unreliable, so using a double is a good way to make your tests faster and more stable.
One of the most powerful tools in writing maintainable code is break large methods into well-named smaller methods - a technique Kent Beck refers to as the Composed Method pattern.
I've recently had a bit of a fiddle squashing some commits with Mercurial, so thought it was worth a post in case anyone else is looking to do this. I don't know whether this is the best procedure, but it seemed to work pretty well for me.
Hang around my colleagues at ThoughtWorks and you soon get the impression that the only good Enterprise Service Bus (ESB) is a dead ESB. Jim Webber refers to them as Egregious Spaghetti Boxes. So it's not uncommon to hear tales of attempts to get them out of systems that don't need them.
AMP, an Australian financial services company, ran an internal conference called Amplify. They asked me to talk about agile software development. I thought about how to make this best fit into the overall flow of the conference, particularly since I expected a significant part of the audience to not be part of IT. I settled on talking about how IT projects can be infrastructural or strategic. This classification alters how you approach the projects, in particular on the way IT and business people should collaborate.
One of the most striking things about the Manifesto for Agile Software Development is the format of its values "we favor x over y". I don't remember who came up with that idea, or how it arose. It probably just bubbled up as we tossed around ideas. But it's distinctive format has led a few people to try using that format again.
Rebecca Parsons and I talk about Google App Engine and the general world of clouds. In the first bit I talk about things various ThoughtWorkers learned from experiementing with App Engine, highlighting issues with testing, persistance, and concurrency. In the second part Rebecca talks about the broader issues enterprises will face with moving to the cloud.
Several years ago, my then colleague Matt Foemmel, dissatisfied with the tools with which we were building software, managed to get in touch with Charles Simonyi to find out more about the shadowy Intentional Software. What he saw impressed him, and he persuaded me and other ThoughtWorkers to get involved too. What we saw was a tool with startling potential, but we remained frustrated by the secrecy and lack of urgency to release. That frustration ended last week.
When I attended DSL DevCon, Microsoft's Channel 9 dragged me off to be interviewed by Chris Sells.
Many computer systems are built to house data and turn it into useful information for humans. When we do this there is a natural desire to make that information consistent. After all what use is there of a computer system that's in two minds about things?
For a talk at QCon London 2009 I surveyed ThoughtWorks use of Ruby from 2006-2008 in which time we did 41 projects. My talk covers our views on Ruby's producitivity, speed, and maintainability. I conclude that Ruby should be taken seriously as a development environment. I also have an article that covers the same material if you prefer reading to watching.
One of the interesting talks I attended at QCon San Francisco, was one given by Greg Young about a particular architecture he'd used on a recent system. Greg is a big fan of Domain Driven Design, in this case it needs to be used with a system that has to process a high transaction rate and provide data to lots of users. There were a number of things I found interesting about his design, particularly his use of Event Sourcing, but for this post I want to dwell on just one aspect - what I'll call Eager Read Derivation.
There's a mess I've heard about with quite a few projects recently. It works out like this:
- They want to use an agile process, and pick Scrum
- They adopt the Scrum practices, and maybe even the principles
- After a while progress is slow because the code base is a mess