Software design

This category contains 34 posts

A small lesson in Scala

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

Your architecture impacts your business strategy

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 healthy

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

Avoiding functional tests

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

Faster builds make better software

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

Why does over-engineering happen?

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

Appropriate complexity for better living

I was recently involved in a great example of software complexity, technical debt, and refactoring, and I want to pass on the experience. As part of a project some new requirements came in. I had been concerned that part of the system under development was a little complex, but not overly concerned, as it worked … Continue reading

Migrating systems (such as Delicious)

A few words on rewriting and migrating systems, based on experience. This is because the painful rejuvination of Delicious under Avos is very much at the front of my mind right now — I’m both a user caught in the backwash, and also an industry professional who’s dealt with these things before. While Chad and … Continue reading

Technology decisions are social decisions

A couple of things happened recently bringing home something that I’ve found increasingly important: technology decisions are social. Social decisions in software architecture The other day in conversation about team structures the Guardian’s lead software architect, Mat Wall, mentioned that architecture is social. This is a good, and often disregarded, observation. In that context he … Continue reading

A software proposal to improve estimation

Previously I’ve talked about estimation, using an example of a project that we were very confident would make a certain amount of revenue. The slight flaw in this approach is that “very confident” varies depending on who’s making the estimate. So here is a proposal for an application to train the user in consistent estimation. … Continue reading

Advertisements