HoM&M Concert thoughts
While waiting for the concert to begin, I was observing the preparations being made on the stage.
And thinking: how does it compare to software development?
I was quite in shock seeing from a close perspective that a group of professionals just comes onto the stage and does their job perfectly.
I could imagine a situation where you can ask someone on the street “Can you play flute professionally?”, followed by a document of finished school/course, and a short demonstration, give that person score (musical notation), and voila.
Now could you imagine asking someone on the street “Can you program software professionally in Python?”, followed by a document of finished school/course, short demonstration of skills, and then give that person a chapter of business requirements and expect that person to produce code in line with everyone else, and the sum of the code being a working software?
Why I am asking this question? Because I believe many people see software development that way.
And yes, I am simplifying, omitting rehearsals, interpretation by the conductor, etc. but that is the way many people see music/software.
If the musician would be in a software firm…
Instead of a score, there would be a direction like “play something fast and funny”, and an expectation to fit into the current theme everyone else is playing.
Surely many people would thrive in that improv situation, but the result may be either extraordinary or catastrophic, and that is not a risk customer would pay for the software that should be just stable.
Composer of diagrams
Why is it working for concerts? I would say “the score”.
There is the unambiguous design (requirements) that can be followed.
In software development, any design is considered unambiguous.
Then you put together people knowing their instruments but not knowing how to “design” the concert (nor the requirements audience has), expecting results.
Why we can never have a good plan to implement a program?
Software development is often compared to construction engineering. There is a plan to build something, and it is followed.
When the plan is completed, the build phase usually takes the amount of time and budget that was planned.
The comparison that is often used to explain the phenomena that projects never work that way in software engineering is along the lines: “Build phase is installing software, creating (coding) it is a design process”.
Music and software development is not something to compare widely, but for performing the concert the similarities are quite visible: having trained people to follow a design. And I think developers often see themselves as craftsmen or artists from a perspective of “knowing their stuff”.
“Give me a task and I will code it!”
A side note: 10 Ways That Programming is Like Playing the Guitar by Sam Koblenski.
Many people see the development as a manual process, where you know concepts (from books or university), your instrument (your programming language), and you know how physically use it (how to work with IDE).
You always know the sound (output) to produce.
Clients have that expectation.
Managers have that expectation – you can hire another “instrument X developer” and just assign him to the project.
Developers have that expectation – they do not want to go on meetings, talk with business, they just want to “write code”.
Is it the right expectation?
“Are developers paid just to write the code?” is a question debated often in our industry.
I am fiddling with it for some time now and I will answer it in the coming posts.