Recently I read Emergent Design: The Evolutionary Nature of Professional Software Development by Scott L. Bain
(on Amazon). It’s a very interesting read.
[E]mergent design works by refactoring and enhancing code, due to the changes, bugs, and extensions that have to accommodate, while paying close attention to these principles of coding. (152)
In order to deal with the idea idea of evolutionary software development with a lean or agile methodology you have to first grasp what software development is and isn’t. As a consequence of this, the first part of the book deals with the idea of “Software as a profession”. A lot of this is very thought-provoking; I’ve never really thought about what a ‘profession’ actually is before.
Software development has not been around for very long, in the grand scheme of things. Other, similar complex endeavors (medicine, the law, architecture and so on) have been around for hundreds, even thousands, of years, and in that time a whole set of standards, practices, and general wisdom has been captured and handed down from generation to generation. This has helped to increase the rate of predictable success for each new batch of doctors, lawyers, and builders, and in each case has led to the formation of an organism we call the profession.
Although he admits that the choice of development as profession is somewhat arbitrary, it does serve to highlight that what we do as developers is like no other activity. In other words, software development is a unique activity, and there’s no point in organising it using the methods of electrical or mechanical engineering, research science, medicine, or house building. Each of these professions is different from software development and different from each other. Software developers need our own ways of organising our field of knowledge, some of these are currently absent.
Features that need to be covered in software development as a profession:
- Specialised language. This would be at a high level, not a low abstraction level like at the code itself. Bain maintains that the design patterns ‘movement’ is a move towards the development of a high-level specialised language that matures our field towards professionalism.
- A clear entry path. Something that’s currently clearly missing, although I’d contend that perhaps a computer science or information technology degree and employment as a graduate programmer, at least in this country (Australia), is something that somewhat fills that role.
- Peer-review. Peer review is fairly ad-hoc and chaotic, despite attempts at things like user groups and websites.
- Standards and practices. Unfortunately there is little agreement amongst the broad software development community about ‘what is right’. However, I would argue that the Agile movement is at least a move in the right direction.
The sorts of things that need to be discussed and understood by a profession of evolutionary software development might number:
- Qualities. How do we know when something is good? How do we choose the best thing? What is meant by best?
- Principles. The fundamentals of good software. “Principles promise better results in terms of the qualities we will emphasize”.
- Practices. The things you do in your daily coding activities. Practices must be easily taught because they “are truly valuable when they are shared and promoted to all the developers on a team”.
- Disciplines. These are similar to practices, but on a larger scale. Things you should do that have a basic and profound value to what you do as a developer. For example, unit testing, refactoring, test-driven development.
- Patterns. What worked before; “the set of interrelated points of wisdom that reflect what [the profession knows] about certain situations … that we find ourselves in again and again”. I would add, and the common, standarised jargon that we use to describe and discuss these patterns.
- Processes. How does development work? How do we know what to build? How do we know when we’ve built it? How do we correct the situation when we discover something’s wrong? How we we discover that something is wrong? Et cetera.
In this day and age I can still find developers, usually working in crippled environments, who won’t even agree on the simple principles of maintaining ‘good’ code practices, for any version of good. Whatever’s there, they’ll accept. Even when faced with seriously broken design, and a mandate to effect change, a cascading series of ever-fragile hacks will be accepted, even if it takes more time to produce, or modify, the hack. Code will never be deleted, even long after obsolescence. It is left remaining, “just in case”, and as if there was no version control system.
As a consultant, I have no real choice but to work with these programmers. I can only try to encourage them to follow a right path. I was recently told I was a perfectionist, simply for demanding any level of unit testing greater than 0.
4 Comments
Unfortunately, industry “best practice” (a sad term in itself) is pretty poorly distributed. Even version control is only used by something like 50% of development shops, despite the availability of good free VCS solutions. Unit testing is in the <25% category. Good quality automated acceptance testing is probably <1%.
Bain’s book is on my “to-get” list (a list that never gets shorter, alas). It does sounds very interesting.
Bain’s book is definitely worth reading. The thing that I took away from it, that gave me the most value, was the idea “what a profession is” (a unique body of knowledge, processes and practices) and the organisation of software development as a profession. All the specific ideas, like test-driven design, and so forth are already known to most agilists or other self-aware programmers (I wish I could say “all programmers”, but alas, your statistics are probably right Robert!), but the insight in Bain’s book is the gathering of all these things into the idea of the “profession”.
As programmers we need to start developing the idea of “professional practice”. And I, like Bain, and probably you too, would say there’s a bunch of basic things we can do get started. Until we do we’re just a bunch of witchdoctors sprinkling chicken blood (aka spaghetti code) over our victims and chanting the magical incantations (“it compiles, it ships!”).
I think you are exagerating those figures. I would contend that far less than 1/4 developers unit test — could be even as little as 1/10 when you take into account the non-java world.
As for VCS — The biggest trouble is that it isn’t taught at most universities/courses, and as such very few people understand basic things such as conflict resolution.
I guess this makes it a good litmus test for people who are able to learn outside a formal environment
Well Ben,
Yes you might be right. Certainly about the Universities, which should be teaching their students ‘how to be good programmers’ first and foremost not ‘how to write XYZ language or feature’. It’s the old adage about being taught how to think, research, find out for yourself – it’s what supposedly separates a University from a TAFE. Allegedly.
3 Trackbacks/Pingbacks
[...] In Emergent Design Scott L. Bain dedicates a chapter to ‘Paying attention to Disciplines: Unit testing‘. To an experienced agilist this may seem a little basic: of course the discipline of unit testing pays dividends! But I think that we agilists forget sometimes that there are still many programmers – or their management – who don’t value the investment needed to get the extensive returns of unit testing and test driven development (let alone test driven design). [...]
[...] big issue I see with these systems is that they tend to be highly resistant to modern programming principles and practices. For example, test-driven design – or even simple unit testing. Sure, if you’re building a [...]
[...] of our professional practices should be the delivery of incremental design to systems. Instead of that 4 month re-write of a small section of functionality could we have delivered it in [...]