I was having a conversation with a couple of friends the other day, when the topic of Software Engineering came up. I have been working in the software industry for over two years. I do not consider this to be a large amount of time. Nevertheless, I have learned a significant amount of software engineering.
Let me back up. In college, most computer science students take a class on how to design and build software, titled Software Engineering. In this class they give you a textbook and teach you the different “models” of software engineering. They present this Utopian view of the software engineering process that I have never seen implemented in the real world. Most of what I see is similar to this graphic I found:
The biggest problem with the software engineering designs is that the business side does not understand the benefits of software engineering. It might be a good idea to force the business people to take a class in the pitfalls of software engineering. I have heard countless stories of people creating rush prototypes of a project, showing it their business sponsors, and their business asking for it be in production the next day. Most prototypes are not designed to be released. Often times they are missing key components of functionality(like login validation).
Now, I’m not saying that software design is useless. It is necessary to to have an idea of what you are building before you begin to code. What I’m saying is that I don’t think that the software engineering process that are described in the software engineering books in school is valid the work environment. It is good to teach them, but teachers should also stretch the variations that occur in the real world.
One last thing, I’d like to make a plead for my favorite design methodology. Test-driven design is a wonderful idea. There are problems with it, the design ends up being only as good as the tests that are written. Most of the time the tests that are written in the beginning before construction of the code are not sufficient for a fully functional program. I feel this stems from the fact that businesses are often rushing to produce something and you don’t see any results while writing tests. I myself have been guilty of rushing people through designing tests when I was in a business role.
To all people who are reading this from a sponsorship position, please allow your developers the time they need to ensure good design. In the end it will help you products.