A few years ago, after listening to a presentation I gave on software release managament, a member of the audience expressed with what appeared to be a mixture of amazement and bitterness that “this should be taught at university as part of every computer science course”. At the time, I took that as a compliment, and didn’t really think about it much beyond that.
But working with spriteCloud puts us in contact with a large number of software engineering teams, which as a rule are comprised of extremely bright, motivated and capable engineers – and yet, despite their capabilities, some issues crop up over and over again.
As QA consultants, we can always advise our customers on the larger processes by which they can keep a project on track, but we rarely if ever can make suggestions to improve code quality before it’s even written.
Specifically, there are choices to be made in code that have are very rarely addressed in the plethora of HOWTOs and guides one can find in bookstores or on the world wide web. Let’s call that code design, and start discussing some of these topics.