Software development, as we know it today, started in 1945 when Alan Turing began writing code, inventing subroutines, the stack, and floating point numbers. Back then, Turing was already worried that the lack of discipline would compromise the success of computing:
“One of our difficulties will be the maintenance of an appropriate discipline, so that we do not lose track of what we are doing.”
—Alan Turing, 1946, Lecture to the London Mathematical Society (AMT/C/32, p18, §2)
He correctly predicted that the number of engineers feeding computers with programmatic instructions would be huge, and considered a certain ability of problem solving to be essential:
“We shall need a great number of mathematicians of ability” because “there will probably be a great deal of work of this kind to be done”
—Alan Turing, 1946, (AMT/C/32, p19) and Proposed Electronic Calculator (AMT/B/1, p18, §6)
Turing understood the problems we would face for the next decade from the very beginning of modern computing.
It’s Our Responsibility To Ship Working Software
Our competitive world leaves little room for excellence — currently. The accidents caused by broken software have not yet been disastrous enough to justify a strong rule set being enforced. Not like Zeppelin and airplane crashes, or collapsing bridges. Events like those will eventually happen though, unless we anticipate them.
“We can’t write tests, because our customer won’t pay the effort!”
—No. 1 excuse for not writing tests
Does your surgeon ask you whether they should desinfect their hands and wear a mask during a surgery on you? Does a civil engineer ask you whether to omit the structural analysis, which may allow you to save money on building a bridge? No. They know they are “engaged in a profession which carries with it grave responsibilities”. Responsibilities that sometimes decide between life and death.
If our industry doesn’t manage to understand that software development requires just that very same caution and professional behavior we need to come out with business ethics that allow us to enforce this thinking. Before politicians do it on our behalf, as a consequence of an event maybe remembered as “the big software accident”.
Discipline Is All We Need
Discipline is what the software development industry has been hunting for for years. Software development projects not only fail due to lack of experience or ever-changing requirements in a fast-paced world. The inherent complexity of writing software, which Alan Turing refers to introducing his quote from above, requires that we all follow a common set of established practices in a very disciplined way. This is more than juggling with deadlines and persuading programmers to implement features faster, things they hardly overlook in their entirety, let alone estimate reliably.
“Why a month? I won’t leave this room before you tell me it’s possible in a week!”
—When POs have to deliver (then talking to developers sounds like this)
The manifesto for agile software development established in 2001 makes these practices visible and describes them by explaining the underlying motivation. They are 4 rules supported by 12 principles, written in the form of a prayer without being religious. Like the 10 commandments Moses carried down from Mount Sinai, 17 senior engineers compiled and explained the rules that are meant to stay. Agile is not a hype. It’s a collection of experience describing the collaborative process necessary to develop working software.
Just being a bunch of happy people fed with snacks, vegan food and energy drinks, reflecting about their tool chain and communication style is not enough, though. Software is starting to control every single aspect of today’s life. We have a tremendous responsibility to make sure what we ship is not causing threat to humanity. And this responsibility is growing with AI and IoT surrounding us.
Responsibility in software development means proving that code continues to work as planned. It’s not sufficient to try out code we write once or twice after implementing. A “proof” in the sense of software development is a test, some other, preferably simple code that can verify that (part of a) software meets a specific behavior. A test is not a procedure carried out manually by a person, a “tester” — this is a manual verification. Tests can be carried out effortlessly in an automated fashion, over and over again, e.g. every time you make a change to your software — which potentially breaks existing behavior.
“Software without (automated) tests is broken by design.”
—Jacob Kaplan-Moss, developer of the Django web framework
When organizations embrace agile software development they typically focus on “self-organizing teams”. This is one of the 12 principles and indeed a very important aspect. Making people communicate and interact effectively alone is not sufficient for success, though, it’s just the basis for building “working software”. Remember that we need to prove that software continues to work to call it “working software”. All this guidance is included in the agile manifesto.
“Agile doesn’t work for all projects!”
—No. 1 excuse of managers resisting to change
It should be clear now that agile software development is more a sign of a maturing business sector rather than a hype of Silicon Valley. Whether or not we apply modern software development practices to doing business is not a question of taste but a question of responsibility.
Our industry has to come up with a serious catalog of business ethics. When software engineering bodies start enforcing those ethics in a way other professions do (e.g. aeronautics, medicine, law) — engineers that violate these ethics may face severe consequences, such as not being allowed to execute their profession anymore — then this will give halt to excuses and lax interpretation of the duties of software engineers.
What Agile Really Is About
Agile is about proper software engineering. And proper software engineering is about discipline. The basis for a successfully executed profession is called “discipline” for a reason. Software engineers need to be able to stand by their decisions. A software engineers code of ethics will make this easier for everyone, because it will establish a common understanding of our responsibilities.
Agile is not a magic way of doing project management. And specifically, it is not a business discipline, away from, above or outside of software development teams. While Agile is meant to serve business through the practice of Continuous Delivery it is and shall remain a discipline of engineers.
Have 1 hour to spare? Watch this talk, a wonderful history lesson of computing.
The conclusions presented in this article are largely drawn from talks by Robert C. Martin, one of the 17 authors of the manifesto for agile software development.
|quote:||Special thanks to Robert C. Martin and Prof. Andrew Hodges for their guidance on finding the original documents of the Alan M. Turing quotes!|
|||taken from “Architects Code of Ethics“, Republic of the Philippines, 2006|