|Home | Portfolio | Articles | Art | Links ||
Tao of Coding
SE is a Joke The Game Loop MVC for Games
Software Engineering is a Joke.
During my studies at the university we had a course called "Software Engineering". The professor of this course strongly believed in the fact that software development would soon evolve in an engineering practice, with strong rules and metrics that will make the development itself more controllable. A specified process will guide all people involved and will eventually guarantee quality. This quality would then be evaluated with other metrics and stuff.
Unfortunately for him and for everyone who wants to become a "Software Engineer", software development and engineering are, even at the most fundamental parts, completely different. Engineering is the practice to develop something touchable, something that obeys the laws of physics. This implies that the product produced can be evaluated with the laws of physics. You can make all kinds of statistics, strength calculations, etc on the product. Engineers can therefore define their requirements with physical attributes, and so they can also be evaluated this way.
Software on the other hand, doesn't obey the laws of physics, by the simple reason because it can't be touched. Sure, it has physical parts, but those physical parts are not that important. Do you think you click on buttons in your desktop environment? Think again, the only thing you click is the button of your mouse, and the virtual push on the button projected on your monitor is just an illusion. Yet it looks, feels and even smells like a real button, great isn't it?
Programmers, just like artists, try to represent the world. They don't model or create real physical objects, they just try to capture a part of the world in an illusion. Programmers do this in both the source code and the final program. The better you can capture the world in your source code, the more understandable it will be. Source code only makes sense if you can imagine what it represents, what it does. Programs only make sense when the user knows what everyting represents: a button, a folder, a help manual. These are all representations of real world objects in a virtual environment, nothing more than an illusion.
The confusion of software engineering probably comes from the fact that programmers often have the same intelligence as engineers, and most of the time share the same interests. It's sometimes hard to make a distinction between programmers and engineers because of their similarities, but that doesn't mean that programming is therefore an engineering practice.
So to conclude: as a software developer you need the brains of an engineer, the writing capabilities of a poet and be able to represent the world like a painter. So don't believe the software engineering hype! So called "Software engineering techniques" can be applied and may be useful to you, but don't believe that they encompass everything. Painters, musicians and writers also use well known techniques, and engineering has nothing to do with it. Your knowledge, skills and most important your creativity and imagination are your greatest programming strengths, use them, because software is created, NOT ENGINEERED!
I receive a lot of reactions on this article, so I am responding here to the most common ones. The most popular reaction is that project X or Y uses a real software engineering approach, and we should learn from them and should work in the same way.
I agree that there are projects that benefit from a real engineering approach, but these are a minority of projects and can't be generalized. When your clients are engineers, you have stable requirements, you interface mainly with electronic components, and the client wants to invest extra money for life-critical software, well, then you could or even should apply engineering practices, formal methods, and you could call it software "engineering". But when the software you develop is for non-technical people, without upfront stable requirements, mainly interfacing with humans, then you're development won't benefit with "engineering", and definitely shouldn't be named "software engineering". And remark that almost all software projects fall in the second category.
My point in the article is that we can and need to get better at software development, but it is my belief that using the "engineering" metaphor will hold us back. A lot of people, maybe even most, believe that we should improve ourselves by becoming "more like engineers". For example by using Formal Methods etc. This might be true for a small number of projects, but it is my belief that for most software projects, as software developers we need to become "less like engineers".
"Engineering is the application of technical knowledge to solve problems.", therefore, engineers try to gain as much technical knowledge as possible to solve their problems. In my opinion software development should evolve to require less and less technical knowledge, that way we can spend more effort on the real problem: mapping the problem domain into a clear software representation. Developing software should evolve closer towards the human side, and not towards the technical side. And so far, programming languages for example have evolved in that direction.
You should also read this great article for some extra info.
Copyright ©2008 Koen Witters