Skip to main content

Second System Effect

Software engineers often stick close to successful designs used in our past. We have favorite tools and techniques that we reach for without deliberation, and the more specialized our knowledge, the more this tendency dominates approaches to software design. How do we know the difference between the best solution and the one that we're most comfortable with? In a word, the answer is experience.
The second system effect postulates that the second system a designer creates will tend to be over-complex for the problem it solves, but eventually experience will help the designer to distinguish between core technique and chance detail. Many online commentaries focus on the way features accumulate as systems mature. There is merit in this view, but I think the key observation is rather that acquired experience is what allows software designers to create more elegant solutions.
Different software design projects build experience in differing amounts. Imagine solving very similar problems repeatedly - each successive solution brings less and less insight, because the core techniques are quickly mastered. Moreover, narrow exposure to problems creates a way of thinking which blinds us of other possibility. I have to leave my comfort zone: for me this is to work with problems long enough to understand them, long enough to distinguish between technique and detail within that space. But not too long.
From the designer's perspective, the second system imparts the most information about the problem domain. Every system beyond that provides diminishing returns. I would pay the price of the second system over and over again.

Comments

Popular posts from this blog

ReactJS, NPM and Maven

I'm just starting to get into working with ReactJS, Facebook's open source rendering framework. My project uses SpringBoot for annotation-driven dependency injection and MVC. I thought it would be great if I could use a bit of ReactJS to enhance the application. If you're looking for a basic conceptual intro, I recommend ReactJS for Stupid People and of course the official documentation  is quite good. In full disclosure, I still have no idea how to do "flux" yet. As an experienced Java backend developer, I'm pretty decent at hacking Maven builds - which is precisely what this blog post is going to be about. First, a word about how React likes to be built. Like many front-end tools, there is a toolkit for the node package manager (NPM). From the command prompt, one might run npm install -g react-tools  which installs the jsx command. The  jsx  command provides the ability to transform JSX syntax into ordinary JavaScript, which is precisely what I want...

Solved: Unable to Locate Spring Namespace Handler

I attempted to run a Spring WebMVC application, and when starting up the application complained that it didn't know how to handle the MVC namespace in my XML configuration. The project runs JDK 7 and Spring 4.0.6 using Maven as the build system. The following is my XML configuration file: <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans"        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xmlns:mvc="http://www.springframework.org/schema/mvc"        xsi:schemaLocation="         http://www.springframework.org/schema/beans         http://www.springframework.org/schema/beans/spring-beans.xsd         http://www.springframework.org/schema/mvc         http://www.springframework.org/schema/mvc/spring-mvc.xsd">          <mvc:annotation-driven/> ...

Capture Everything

This week I've started planning for the next version of our data collection system. The key realization for me is that I do not know all the questions we will need to answer in the future. Our current focus is on specific sequences of click events, but in the future we might want to look at browser versions or behavioral patterns related to IP addresses. If we don't capture user-agent, for example, we won't be able to answer questions about browser versions. If we don't capture IP then we cannot look for patterns in IP addresses. We should store data in a way that maximizes the range of questions we can address in the future. In the past few years, the cost of storing data have continued to fall. We use AWS extensively.  Amazon S3 costs are very reasonable and guarantees a high level of availability. Also, lower compute costs and open source tools like Hadoop that process large data volumes have greatly increased our ability to extract valuable insights from data. So s...