Software development? What is it? Well, it is everything that must be done during the creation of software (and to maintain it and keep it working), or as Wikipedia defines it “it includes all that is involved between the conception of the desired software through to the final manifestation of the software”. We can engage into software development for several reasons: it could be for fun, it could be for learning, or to make a living… to work in the industry… to be a professional.
I’ve been working as a professional software developer for 10+ years, and something that I like to think about, or to philosophize about, is the 2 main approaches to software development; as an art form and as a science; or more precisely as a craftsmanship and as an engineering.
But first, let us discuss what the difference between a craftsman and an engineer in the software development context is:
Developers with a strong craftsmanship approach will first trust their gut and instincts during problem solving when developing software; they develop based on prior experience, based on the knowledge they have accumulated from performing their craft over the years and from their mentor’s teachings; much more like a carpenter that is building some furniture or as a musician that is writing a song or as a writer that is writing a novel.
Developers with a strong software engineer background will create and/or follow a process, will split the software in smaller parts and tackle them individually; they will use industry patterns and best practices when solving problems, they will measure and calculate their development velocity, quality, and use engineering tools and techniques; they rely on industry standards, practices, processes and methodologies created over the years. They trust numbers, data and history from previous projects to assess their approach in current ones.
Though all developers are a combination of both, most lean towards one or the other.
So, is one approach better than other? Do we need to teach software development to new generations in a different way? Will one of these approaches guarantee success on software development projects?.
Certainly not, and that is something history has taught us well; you just need to take a look at the many reports published by Gartner, IBM, and several universities (like the SEI at Carnegie Mellon) over the 70’s, 80’s, 90’s, and the past decade to get an idea of the high percentage of software development projects that fail, but that is not all, we must also take a look at the evolution of software development: during the adoption of software engineering (60’s and 70’s) we saw the rise and fall of several so called silver bullets that will come to save us all and didn’t (take a look at Fred Brooks paper “No Silver Bullet” published on. 1986) And the changes that we have seen over the years in the industry: the creation and evolution of software development methodologies, the rise in popularity of RUP (iterative models) in the 80’s, the rise of the agile movement on the 90’s and its rise in popularity in the first decade of the new century, the creation of the Capability Maturity Model (CMM and CMMi) and Information Technology Infrastructure Library (ITIL) and the many proposals on project management like the one done by the PMI.
In my personal experience I have seen many projects succeed and many others fail; at the beginning of my career I was very interested in software engineering and thought that by defining processes and sticking to them, by using the best tools, practices and techniques from the industry the projects will always succeed, but that was not the case.
Latter when I started to realize that software development was a creative process done mainly by developers, I started to learn and believe that treating it as an automated production line was a mistake; that we can’t think of developers as machines that will always perform the same; the idea of “the same programer using the same set of tools and following the same process will always produce the same results to the same problem” began to fall apart. Reality is that we can hardly use the same tools, as technology is always evolving and a proven right way to do things often changes as time passes; also as with any other manufacturing process the quality of the product depends on the quality of raw materials, processes and tools used to build it. In the case of software development, the raw materials are the knowledge of the developer and the main tool used is his/her mind; thus the quality of a piece of software will be highly dependent on the state of mind of the developer… and that varies a lot, as it is affected by mood or other factors (e.g.illness or tiredness).
So I started to gravitate towards software craftsmanship and the belief that truly knowing our craft will help us achieve successful projects. And yet I saw projects that used primarily this approach fail (something I expected, as I gave up on a silver bullet a long time ago)
Truth is that building software is not like building a car or a TV set; software is mostly developed by humans, and not by machines, and it is not a repetitive task to automate; as the primary way to develop software (at least for now) is by coding, or writing instructions in an editor using a programming language, this task is more of a creative exercise on problem solving than repeating the same movements with your hands and arms. So, developing software is more like writing a book than building an object. Have you heard of any factory that has a production line to create the content of books?
Yes, develop software is more like writing books, but a book in which its contents are created by several authors at the same time, and which are not a work of fiction but rather a clear set of instructions on how to solve one or more problems.
… software development is a complex task indeed.
This is what we, as developers, face on every project, and we as software professionals must know it and understand it; certainly the challenges are many but the rewards (as on any other creative process) are worth it.
In the meantime I have learned that there is no better approach, both approaches are equally useful when developing software. We must take advantage of both, we must look for best practices and use the proven patterns, figure out the best tool to use at our disposition, follow the processes (but not blindly, criticize it when it is the best thing to do), measure and estimate, read the numbers while keep on learning your craft and learning it well, pick good mentors and learn from their experience in order to form your own.
I truly believe that being a good craftsman and also a good engineer is the best bet towards the success of software development projects.
