Todays programming languages are just amazing, sure they will continue to get better and better, but right now they are pretty damn amazing. It is impossible to learn everything there is to know about even a handful of them, and if we are honest, without the luxury of time most of us are sadly lacking in proficiency. In this Pantheon (considered either by beauty, elegance, capability or a dozen other criteria) I personally would place at least Scala, Clojure and Haskell.
So, what is the excuse ? Why the complexity and limitations in software engineering ? The answer is simple. Us. Human beings. In fact, it is so bad I cannot even categorise between those of us who are technical and those who are not, (as a techie I am of course biased towards blaming those who are not technical, or technical _enough_ for all the problems).
We are slaves to so many bad habits, and philosophies that it is almost a miracle we ever get anything right. I am guilty of it too. I will not try to list the bad habits and philosophies that I am guilty of as there are so many :-) , but I will list those I have witnessed in others. To avoid being purely destructive I will also point out possible fixes I have seen (both ignored and implemented).
So in no particular order, and with no particular definition of complexity here are some bad habits, and their causes:
1) artificial technical constraint imposition
- agenda (insidious and ubiquitous)
2) artificial deadline imposition
- lack of strategy
3) poor role definition and allocation of resource to roles
- lax recruiting
- lack of understanding of the capabilities of resources
- using the wrong tool for the job
So, what kind of evil do these habits let in to your organisation ?
- rushed, unmaintainable, unstable code
- lack of exploitation of the magic and power of languages, toolkits and frameworks
- the death of motivation
- the death of projects
How do we fix the three problems isolated above ?
1) Ensure the agenda of 'the business' is always placed above the agenda of any individual. This requires good communication between key project stakeholders and business domain experts and the technical teams who will be delivering on projects. Managers need balls to sort this one out, shots may need to be called to replace individuals who are 'jamming the signal'.
2) Ensure the business and technical teams work together to define sound strategy. This needs to go through some rigorous processes, and needs buy in. It is ridiculous to impose deadlines on technical teams without consulting with them. An act of lunacy.
3) Sometimes, due to either agenda or perhaps just incompetence, a resource may act like a signal jammer. Communications break down, and a project starts to fail. Once again this needs to be recognised at a higher level. Restructuring is _always_ the right thing to do here. Why use the wrong tool for the job ?
Just as a system comprised of quality components with a clear signal works beautifully, so too does a team comprised of quality resources with clear communications.
Just as a system comprised of quality components with a clear signal works beautifully, so too does a team comprised of quality resources with clear communications.
