Nicole Carpenter
Web Developer

Questioning Software Engineers


31 Mar 2016

I personally have never paid too much thought as to what makes someone a “software engineer”. To me, engineer was always more of a loose term for someone whose college degree contained the word “engineer”. I remember my Information Systems management professor citing that somewhere around 4 out of 5 “engineers” are actually just project managers. Those numbers have not been independently verified, but I see where he was going.

Software Craftsmanship by Pete McBreen gets more technically into the role that software engineering has held throughout the short history of programmable entities. In McBreen’s view, most modern software projects do not need to be engineered. That speaks to both what engineering actually entails, and the shape of modern software requirements.

The IEEE states the definition of software engineering as the application of a systematic, disciplined and quantifiable approach to the development, operation, and maintenance of software. The author explains that for some projects, this approach is appropriate, mainly for larger-scaled, or safety critical systems, or when there is a systems engineering project involving both hardware and software.

Yet, that is about where the necessity for engineering ends. The reason for this is that there are usually trade-offs with an engineering approach, not the least of which being cost. When the consequences of errors are grave, however, that cost may make sense.

Another reason software development does not necessarily fit into the scope of engineering is that it is not always easy to develop software in a systematic and quantified manner. Projects requirements are flexible. This approach does not take into account the value that the humans play in a project, both developers and users.

Every developer is going to have something to bring to the table- different experiences, different knowledge of the system. Real people have the benefit of being dynamic and adaptable to change. Automation can solve some problems, but people fill the gaps. Besides that, it is users that are behind user stories, and those user stories are not always simple to put into neatly packaged boxes.

So with these considerations, engineering software is perhaps not the right approach. And this is where craftsmanship can emerge.

When I think of a craftsman, I think of both skill and artistry. I think of a sculptor, creating beautiful lines and curves out of marble. I think of a carpenter, whose meticulous seamwork and strict precision creates structures that stand the test of time. I think of a surgeon, skillfully interacting with their patients in the most intimate of ways. None of these people started out great. They had to start somewhere. They had to learn and be taught. They had to gain knowledge and experience in order to become experts in their craft.

That is what I am striving for. I realize that I have so much to learn and years of experience to gain. I am truly embracing being on the bottom rung of the ladder, because I can look up, and see that there are so many rungs above me that I will be able to experience. Each rung provides me with a new perspective, even if it is only a difference of 12” from the last. Small wins. Constant ascension.