Most tech people I know agree that solutionizing is a bad thing. This is when the non-technical “customer” (a project manager, a product owner) tries to specify the technical solution for the development team. They may sketch out the architecture, specify how files need to be parsed, or (in extreme cases) detail extensions to the … Continue reading
Your software may be designed to work. But is it designed to be delivered? That may sound like an odd question (“Why wouldn’t it be?”) but I’ve been involved in plenty of projects where the delivery process (release, operationalisation, etc) is long and laboured. The reason is in the design. We can design for may … Continue reading
In the ideal world a technology will be selected on its own merits alone. But we don’t live in an ideal world, and every technology has to work in a specific situation. So sometimes choosing a technology because lots of other people did, too, isn’t such a bad idea. Some time ago I worked with … Continue reading
If you’ve got a bit of development experience it’s easy to criticise the technology efforts of others. If you’ve got more than a bit of development experience then it’s harder. In short: criticise if you’ve been there; be careful if you haven’t. I was reminded of this a while back when I saw a retweet … Continue reading
For fun, I’ve been working through the recent Coursera course on functional programming with Scala, run by Martin Odersky, Scala’s creator. It’s been a good ride, but towards the end I started having a new feeling — a real sense of wonder — and I want to share that. This shows a bit of the … Continue reading
On and off over the last few weeks I’ve been thinking about Elaine Wherry’s painful story of hiring developers. But the thing that triggers the whole tale is worth drawing out further: Our homegrown JavaScript framework edged us over competitors but maintaining our technical advantage meant carefully crafting a lean, delta-force Web team. Though I … Continue reading
Technical debt is not necessarily a bad thing. In fact, having it at all is a healthy sign. Some may think otherwise, as suggested by this tweet from Benjamin Mitchell, which was tracking the discussion at Agile on the Beach last week: Making technical debt visible might help, but how does it address the causes … Continue reading
This is third in an accidental series on testing, and today I’m going to walk through a thought exercise in improving test times. This follows directly from last week’s post about the 10 second build, and challenges the assumption that end-to-end functional tests are essential. You’ll recall that Daniel Worthington-Bodart asserted that software build times … Continue reading
The other day I watched Daniel Worthington-Bodart’s presentation on 10 second build times, and was most inspired by the idea that software which runs through the build process quicker is actually better-designed software. Daniel’s premise is that he hates software that takes more than 10 seconds build — which includes running tests. He’s therefore been … Continue reading
I don’t normally find myself in conversations about over-engineering, but the subject came up twice last week, and that gave me a chance to think about the issue. Senior execs and project managers can be worried that developers over-engineer software, thus costing them unnecessary time and money. Undoubtedly it does happen. So, why? The first … Continue reading
