Introduction
During my entire development career, hell my development life, I've dealt with programming languages and machines that have allowed me to write less than ideal code and get away with it. As I moved into the corporate world of development, I met your old school developers. When I say old school, I mean COBOL developers. You know what they say about COBOL developers: They are either retired or dead (COBOL developers start writing your nasty comments... now!). But seriously, these developers heralded the start of enterprise development and really helped build IT as an industry. So I was having a conversation with a COBOL developer and he said that when he is developing, he has to worry about every piece of memory that is being used. He said he was meticulous and could tell you every aspect of how his application interacted with the machine. Now let's consider for a moment that he was telling the entire true, ignoring the usual developer boasting, and then it is pretty amazing considering what developers get to do with today's technology. So I've compiled a list of things I feel developers take for granted, and have taken away the engineering aspects of creating software.
Garbage Collection
When is the last time you had to worry about allocating and de-allocating memory addresses? Garbage collection (GC) is one of those things we don't think about as developers utilizing newer technologies like JAVA Java, .NET, and Ruby. We create objects like they are going out of style because as developers we say things like "memory is cheap" or "the GC genie will handle it." In most instances, the standard GC works great and you can continue creating more objects.
Reusable Code and OOP
I know we take this for granted and I have attempted to teach COBOL developers OOP; it was painful. The fact that I can create a class that is reusable across applications and assemblies is great. How many times am I going to write an Address class? The problem here is OOP can be abused. Inheritance is a tricky thing, and you might be tempted to inherit from a class that doesn't necessarily match your inheritance tree. I have seen old applications that have no concept of OOP, being completely linear; there is usually one big Main method with calls to other functions.
Great Hardware
Developers always want a machine that can keep up with them, and with today's technology you have just that. No need to worry about resources for your program. Short of writing infinite loops or deadlocks, most applications will work (not great, but still work).
Integrated Development Environments and Productivity Tools
Visual Studio, Eclipse, RadRails, and other IDEs make it a breeze to create an application in no time. Code generation and productivity tools make things even easier for a developer. I like IDEs. Now try coding a .NET 3.5 application in notepad. You could probably do it, but you would probably also shoot yourself. I also can't tell you how much I love ReSharper; it always feels weird without it.
Frameworks
Most languages come with some sort of framework that helps you write your application faster. I know how a Stack, Queue, and Linked List work, but I don't want to have to write it every time I start a new project.
Internet
Have you ever started and finished a project without going on the internet to find a solution to your problem? Of course not! (If you say yes, then I call BS). Imagine the days of development without the internet; you probably had a big bulky book about the size of a bookshelf. No thank you, I like indexed and searchable electronic references.
Conclusion
So why do I say Software Engineering is dead? I don't mean it is dead completely. There will always be those who have that engineering spirit, but as an industry we have moved more to an assembly line mentality. We are given a task and we are expected to finish it with the deadline being the most important aspect. The things I've mentioned above let the IT industry function in that way. As an industry, we can churn out applications that are less than ideal but that function enough to make the clients happy. Aspects like efficiency and speed are almost moot with today's technology. Obviously, if you write a crappy application then it will be a crappy application. Engineering involves metrics and when is the last time you heard anybody using metrics in the application development process? The death of engineering is not necessarily a bad thing, but it is a signal that there will be more software developers and less software engineers.
Subscribe