Should our methods and processes be consistent?
A foolish consistency is the hobgoblin of little minds. This famous quote from Ralph Waldo Emerson explains the difficulty many of us have with admitting that we have been wrong in the past and that we see things differently now.
I suffer from plenty of foolish consistency. I notice it with these newsletters. I agonise about what I write just in case it is inconsistent with what I have written before. But really I should have the confidence to write each piece afresh, with the best ideas I can muster, and not worry that I might contradict what I wrote before.
This week my mind has been anything but consistent. This week two very different thoughts have been floating about in my head.
My first thought is that we should move away from engineering-led development. I enjoy writing, and the really good thing about writing is that it is so flexible. You can jot down some notes, write a few paragraphs, do a bit of an edit, rearrange the document, and so on. Systems development is so rigid by comparison, designing systems and data, writing complete programs, testing. Surely we could take a more fluid approach, jotting down ideas and following parts of the solution through, without the whole engineering-led rigmarole.
My second thought is that it is really important to develop software properly. I get involved in configuring a lot of assessment solutions. Most of the time the solution design is trivial - ask some questions, show some results - and we spend our time working on the wording and formatting of questions and outputs. But we have picked up some work recently that is centred around a database, with assessments feeding in and out. I have been thinking how we need to do some more formal analysis and design, to make sure we have the data designed properly, and understand the processes around the solution.
These two ideas are inconsistent. On one hand, I want to move to a more fluid approach to development, on the other a more rigid, engineering approach. When the two ideas surfaced at the same time I didn't know what to think. Which idea was right?
Of course I could make the ideas consistent. My first thought was about how to develop: being more intuitive, following what seems important, building iteratively. My second thought was about the fundamentals of the solution, understanding the solution's purpose and structure before you start. I could argue that I wasn't being inconsistent, and that really I was looking at different things.
But perhaps it is foolish to look for consistency. As much as I can try to make these ideas come together it would be wrong, and I should recognise that they are inconsistent, different approaches. Management is all about picking the right response. Sometimes we need hard engineering, sometimes a more fluid approach. Different approaches have different advantages in different situations. To be really effective, we need to be inconsistent.