Software Engineering is not about code

Shailen Naidoo - Feb 15 - - Dev Community

There is a strong possibility that I might get a lot of backlash from developers all across the Internet but I need to share my viewpoint on Software Engineering with whomever is interested in my viewpoints.

I believe that software engineering is not about code as most developers believe it is about. To me, code is nothing more than an implementation detail to execute a set of instructions which was architected by a software engineer. What is of higher importance is the design documentation or the technical documentation surrounding the software that is going to be built. The underlying tools and technologies that are being pulled in to achieve a desired outcome concerning the design documents are nothing more than tools and technologies.

An architect who does the blueprints for a skyscraper has to take into consideration numerous factors beyond just the tools and materials (technologies) that will be required to achieve the development of the building. There are factors such as:

  1. Wind
  2. Foundation
  3. Sewerage
  4. Stress points
  5. Legal documentation
  6. Clearance from the City.

There are numerous other factors that one needs to take into consideration beyond just the tools and materials (technologies) when it comes to developing a building. The same applies to software engineering, it amazes me how developers are more interested in the raw development of the application instead of taking the necessary time to sit back and just write up a design document for what the goals of the project are.

Code is not important, code is nothing more than a hammer or piece of wood but it does not form the entirety of software engineering. The day a developer decides to write less code and starts seeing control flow statements as a ticking time bomb is the day that they have reached a place of maturity in their field.

Do not show me the code, show me the design document for whatever it is that you are doing. Most developers want to create the path whilst validating their ideas but this is an immature way of approaching software, one should aim to clear the path during the design document phase and then pull together the tools and technologies needed to achieve said design.

. . . . . . . . . .