Software Developers Do Not Build Widgets...

This post will be quite different from my normal posts. It is not a quick how-to, or a design pattern, but a rebuttal...

I was recently reading the introduction to a book on enterprise architecture. And the author tried to make the point that software development is a cottage industry because the "widgets" we create (software) does not have the associated factories, structures, and automation that making cars or cookies has. He points out that the auto industry spends 80% of its time designing the factory and only 20% designing the cars. At the end of building a particular type of automobile, the factory line is thrown away (or massively retooled) for the next model of car.

That author, and almost every other like-minded author or speaker I've ever heard of is building a case for their "software creation" automation tools, process, or methodology (shudder). And their analogy is completely wrong.

The truth is, we don't build cars or cookies. Every custom developed piece of software is different, every car or cookie is the same. We are not the mindless robots in the production line.

We are the engineers designing both the car and the production line.

In the world of software development, the factory is the application or system. The car (product) is the data that is being processed. Whether for internal or external consumption.

The purpose of of the factory is to take in supplies (raw materials, parts, widgets) and to produce product (more parts, or processed materials, and widgets), our software takes inputs (user inputs, inputs from other systems) and produces product (more data, or outputs to other systems).

The efficiency of the factory is completely dependent upon the architect, the effectivity of the system is dependent upon the software architect and developers.

Our tools resemble those of the design engineer or the automation process engineer. We model flows and structures. We specify tolerances and dimensions and interfaces. We are concerned about parallel and serial processes. We are the engineers that we have euphamistically claimed to be.

So, no, dear author, we don't design and build widgets, we design and build factories. Our factories interact with and are operated by users. Do we need process? Yes. Do we need procedures? Yes. Do we need tools? Yes.

Compare the number of moving parts in enterprise software to the moving parts in the factory that builds cars if you must, but do not compare websites and say that they are as similar as two cars rolling off of an assembly plant

If anything at all, compare building entertainment software development and production to the production of movies, and the development of e-commerce software to the development of a new commercial franchise.

Is it any wonder that in an information age, we would need to build information factories?

Comments

Post a Comment

Popular posts from this blog

Database Projects, SQL Unit Tests, and TeamCity

Image
Continuous Integration  is a really good idea, especially when you are working with a team of developers. There are lots of tools out there that can help your team build better quality into your application. TeamCity by JetBrains is one such tool that has been around for awhile; specifically, it is the one that my company uses. Visual Studio has Database Projects   SQL Server Data Tools  to address some of the inconsistencies that developers face when using a database as a storage layer; Things like version control and consistent deployment. It also includes SQL unit tests , which fills a huge gap if any  of your logic is in the database. Many organizations moved away from logic in the database years ago because it was tricky (at best) to verify logic on the data tier, of course, they were also making changes directly to the database itself... but I digress. If you are using SQL Server Data Tools, and run your unit tests locally, it is a joy to behold. Your database is automatical
Read more

Brent: Programmer. Gamer. Cheapskate. All around good guy.

So... not being one that can leave a sore spot alone, when Brent Brown sent me an email Brent his "preferred" blog link so that I could update the link I had created to Stubenville , I naturally couldn't just update my previous blog entry. I needed to take the opportunity to pour lemon juice, salt, and vinegar into the wound until it became a pulp of agonized flesh. It may be because that's the way I am, but it may also be because Brent really needs this kind of opposition in his life. After all, he has a wonderful wife and cute kids, but as far as I can see, nobody that really gives him the harassing that he needs to keep his life in balance. That's where I come in. I don't know what the big deal is... after all, I liked the Stubenville (not Stupid-ville, that's a whole other wound that needs opening from time to time) thread. However, since he isn't there any more, I suppose that it has a limited shelf life. So, if anyone actualy reads my blog, you
Read more

Building nice XML from SQL Server Tables

The XML functionality of SQL Server is vast, however, the best subset of that functionality that I've found may be demonstrated in the following example: Unfortunately, the example result is listed before the code. Join all the desired tables together Set the desired root element Set the path to an empty string to avoid an extra XML element at the root of each resulting row Provide an XPATH name with attributes for each of the desired columns (select * doesn't work well) Keep all the selected columns together by XPATH name or you'll split your xml attributes See my next blog entry for my best way to shred the xml
Read more