Requirements Definition: Programming edition

I really enjoyed this post from DHH at Basecamp.

He’s talking about how Ruby on Rails is more implicit, because it’s designed for a different use case than other programming languages. His key observation is that different programming languages/frameworks are designed with different programming styles in mind.

Different programming languages/frameworks are not only for different kinds of output – embedded systems, websites, apps, etc – but for different kinds of development. If you expect your programmers to leave every year, you’ll standardize how you write code differently than if you expect the same person to be around for a decade.

It’s an interesting thought; that you could analyze the codebase of an organization, and then discover certain elements of an organization’s culture. Here’s a GitHub-trawling project for someone – look at different organizations’ code bases and see if there are indicators that signify their corporate culture. I’d expect to find a few obvious things – comment style/frequency, etc – but there’s probably an indicator related to implicit/explicit code, along with the number of lines of code needed to solve a problem.

On a different note, it’s interesting how the programming style and framework choice is defined by different requirements – some based on the output requirements, some internal (people, culture). We spend a lot of time thinking about the output requirements, but not the impact it’ll have on our internal systems.