Mythological beasts of software development
updated 4 months ago; latest suggestion 4 months ago
There are some powerful myths in software development that we all know to be untrue but still manage to get in the way of us writing good code.
I would talk about some of the more widespread of these myths, drawing parallels with ancient Greek mythology and then make some suggestions for ways of keeping these beasts in check.
In my experience these myths are remarkably tenacious crossing teams,, development methodologies and programming languages and so, although I would make this talk with a Ruby savvy audience in mind, very little of the talk would be Ruby specific.
This talk would probably fit into 20 minutes.
Suggestions
-
James, an example of a myth that I thought I would cover is,"My code must be optimised for speed".
We know this to be untrue and yet there is something very attractive to programmers about making something faster/more efficient. It can be tempting to mangle perfectly good code in an attempt to make it more performant, even where the performance gains are either unnecessary or non-existent. I see this as the source of a many of the most painful examples of code I have seen (both my own and others) in my many years as a software developer.
Roland, I was going to focus on myths that impact directly on the decisions individuals make as they writing code rather than the sorts of myths that build up around interactions within teams/clients etc. and so they will lean towards technical implementation rather than process.
-
Roland Swingler suggests 4 months ago
Yes - are you thinking more around process myths or technical implementation myths?
-
James Adam suggests 4 months ago
I think it would be useful to give one or more concrete examples of the myths that you have in mind.