management

Software Engineering is Not Engineering (More Like Art)

Recently I had an interesting conversation regarding whether or not software developers were engineers or not. The most compelling argument that they could provide for why Software Engineering was truly an Engineering discipline centered around the fact that Universities and Colleges have their Computer Science group in the Engineering department.  That is not sufficient in my mind to by default call Software Engineers well, Engineers. Why? Consider the following

Engineers who build skyscrapers, airplanes, bridges and products that require low tolerance for defects are often operating under the laws of science and as such require that they account for many scientific elements when building their products.

They perform a great amount of 'testing' both in theory and with product before something is released for use.  Their engineering practices are based upon scientific principles that go through extensive peer review and have been building in knowledge for hundreds if not thousands of years.

Now lets look at the definition of Engineering:

  1. The branch of science and technology concerned with the design, building, and use of engines, machines, and structures.
  2. The work done by, or the occupation of, an engineer.
  3. (Business / Professions) the profession of applying scientific principles to the design, construction, and maintenance of engines, cars, machines, etc. (mechanical engineering), buildings, bridges, roads, etc. (civil engineering), electrical machines and communication systems (electrical engineering), chemical plant and machinery (chemical engineering), or aircraft (aeronautical engineering)

Though of this I think can be applied to the science of computers, ie the hardware = Machines I don't however see much if any of this being applied to Software Development.

A paper in 1996 (William Aspray, Reinhard Keil-Slawik, David L. Parnas) talks about some of the reasons that writing code isn't associated with Engineering:

"Computer science is often characterized as an engineering discipline with the systematic study and development of software as its principal subject matter. Software Engineering, however,although combining both key words, has not become a central discipline in most computer science departments.  In many respects, this discipline embodies the same ideosyncracies that can be observed within computer science as a whole such as:

• Highly innovative and rapidly changing field with no broadly recognised core of material that every practitioner must know; • Few results are supported by empirical or comparative studies; • Work within the field older than 3–4 years is rarely acknowledged or referenced; • Old problems are given new names and old solutions overlooked; • Evolution of the discipline is tightly coupled to economic and societal demands; • There is a need for interdisciplinary work comprising e.g. mathematics, psychology, business or management science, … ; • Continuing debate about whether there should be a discipline called software engineering, and if so, whether this should be treated as another discipline among the set of traditional engineering disciplines."

As you read through this I think we can start to see a clear delineation between the disciplines required of 'Engineering' and the disciplines that Software Development requires (Note - This is not an article to criticize people who write software, but rather a way for us to better understand how to manage them and how to help them deliver even better software)

Go to almost any software development team and you will find a mix of people who have ended up going down the path of writing software, they can be people who were Computer Science majors all the way over to people with a Liberal Arts degrees.

The languages that allow us to write software today have matured over the years and as such have become easier to learn and work with.   This mix of skills and backgrounds is not bad, but it deviates from what an Engineering team building an airplane might look like.  Full transparency here, I have never worked in an organization that does true Engineering, but I know many people who do, and I suspect that you would not find people who are designing/engineering bridges or airplanes who don't have a strong educational background in Engineering, but you will find these people in your software development teams.

So why is 'Software Engineering' more art than science?

I think that Software Development is more art than science because we must create software that we interact with on a more human basis.  Creativity abounds in web development as we continue to strive to bring intuitive and easy to use interfaces to the people who are our 'users'.  The people who write software must be able to synthesize multiple layers of code, from Front End to Back end and everything in between. This talent is probably more aligned to writing a symphony in that you have to deal with an entire array of players, each with different instruments (API, Legacy, etc..) and when you get it right you get beautiful music, when you get it wrong you get noise.

When writing software we have the option to try multiple paths to an end, whereas when building a bridge our ability to deviate from proven engineering practices success is much more limiting and catastrophic when we do when we don't.

One can also argue that the newer languages being created are designed to make writing software more accessible to more and more people who have not be through a computer science programs, we are striving to get our languages to ever more English like syntax.

Consider also that people who write software are not held to specific engineering practices.  Software, as it has evolved, has provided people who 'develop' software product with endless ways to implement it the underlying code.  The fact that there are not any set standards that every Software Engineer must use I think clearly shows that software is not a true engineering discipline, but rather a creative one.  Artists embellish, they innovate, the push boundaries into new ways of performing....I think this better describes many of our software developers more than engineering.

The beauty of current software development is that you have the ability to envision new ways of implementing code that delivers functionality and in doing so create new coding processes that others can use.  Software languages provide many different ways to write code to deliver a product functionality, that might be 3 lines of code or it could be 100, it depends on the background and experience of the individual writing the code.

I think when we start thinking about how to manage and support our Product Development teams in our organizations we would benefit from providing them the framework that encourages high quality through innovation, failing fast, and supports both the individual and groups ability to determine their success.  That is not to say that Sr. Leadership doesn't play a part here, it certainly does, by providing clear vision of what is wanted (think of a symphony conductor, who must bring out greatness while providing their interpretation of a particular piece), an ability to accept failure as part of success and a fearless ability to have confidence that when you provide the other two components people will bring greatness as a by-product.

Artists operate in a very Agile manner, we listen and feed off of each other and in the process discover new ways to approach our art. Listen to jazz music and you see the elements of Agile and creativity evident as the small group (Scrum team) takes a song and through listening to each other can create new music, sounds or approaches to an old song.

As with Artists, Engineers don't like to be told something can't be done, that quest to make something happen that has never existed before is what an artist strives for, there is an emotional rush that comes with artistic creation and I think the same is true of software product creation.

Engineers who build skyscrapers, bridges and planes are no less artistic or innovative in their designs however they must take a much more rigorous approach to what they deliver, they simply don't have the ability to go back and redo it.  If they get it wrong people die, though there is of course software that is also mission critical, but for the vast majority of us who develop software for a living, we are able to take a less rigorous approach when we create our products and we expect in Agile to move to a continuous delivery model so our work is never 'done'.

Agile and the Management Impact

You're a technology manager in an organization that has decided that they are going to adopt Agile.  Thunk......now what? You've spent years becoming the high performing manager you are today, managing the day-to-day details of your team, holding things together, making decisions big and small....You are the leader, success of your team hinges on your ability to make decisions that impact the way the team works. Your team is successful because of your management efforts....Sound like you?

This Agile thing is telling me that my teams are now going to be 'self-organizing' and be able to make decisions on their own...what the heck am I going to do?

Managers who are asked to move their organization to Agile may often believe like they are providing the path to the doorway out of the company.  This resistance can be one of the primary impediments to successful Agile adoption and as an organization Sr. Management needs to be aware of this paradigm and provide support to middle managers that Agile is not about replacing them but truly about getting them into a position where they are focused in the truly valuable parts of their job - Strategic Planning, Employee Development..the bigger picture.

Stephen Covey teaches that successful managers are the ones who are able to remove themselves from the quadrant of activities that are Urgent and Important and focus on the activities that were Important but Not Urgent, meaning remove yourself from day-to-day decision-making over planning and strategy development.

So many of us can get sucked into the day-to-day minutiae of our teams that we end up ignoring the bigger picture areas which should be our focus.  Why?  Because dealing with Important and Urgent activities is an addictive feeling, you feel like you are making important decisions when in fact your team is probably more than capable of making them without you.

Agile provides your team with leadership opportunities that aren't found in more traditional process control organizations.  Step back and let your team grow.  I've been amazed how teams, when given the opportunity, can solve process issues and impediments to productivity that I would have never thought of.  The collective minds of your organization are capable of great things.

As a manager you need and want to embrace this power and provide support for you team.  Let them help you and help the organization deliver on the promise that Agile provides.

How can you help?

  • Understand that for your teams to succeed they need to fail, yes I said that.
  • Don't attend their ceremonies (standups, retrospectives)  Why?  The team needs to be able to speak openly and honestly about what is working and not working without you being present.
  • Use the working metrics available to you, velocity, burndown.  If your team says they are going to do 'x' story points and they do that consistently, what else do you need to know?
  • Don't force your opinions on what they 'SHOULD' be doing.  Have confidence that you have hired great people and they like you want to succeed.
  • Work closely with the Product Owner and Scrum Master to discuss any concerns you have.  Understand why things are working a certain way before leveling your judgement.
  • Don't act as a Scrum Master or Product Owner of the team. Why?  You manage their careers and it's highly unlikely that the team will receive the benefits of iterative continuous improvement if they don't feel confident that they can say when things aren't working well.
  • Don't believe that everything is great the way it is, anything can be improved.

Agile will provide transparency with respect to the areas of your organization that isn't working efficiently.  As a management team you will need to focus your attention on addressing these impediments as your Agile teams mature.  If these hurdles and impediments aren't dealt with you will reach a ceiling on the ROI that Agile can provide.  As with your teams, management needs to be honest with themselves about broader organizational issues so that a stronger and more effective organization emerges.

Agile isn't just about delivering software faster, it's much more than that.  Understanding that will make the transition your Agile smoother.

Member Login
Welcome, (First Name)!

Forgot? Show
Log In
Enter Member Area
My Profile Not a member? Sign up. Log Out