Creating software, i.e., being involved in the whole development cycle, is just like creating a music concerto. If you're the team manager, or an independent developer working alone, you're a software composer.
Your composition is the software itself, but it appears before it's done, inside your head. You can visualize it, use it, imagine every component, how all things come together. When you're designing it, you choose your instruments, in this case, your platform, programming language, frameworks, libraries, etc.
You iterate through the programming stage, until you get it right. Sometimes it doesn't sound like it did in your head. You start making some trade-offs. Maybe your team, your musicians, are not good at playing their instrument. That happens. But as a composer that you are, you can take control of it, because you know how to play every instrument. You show them how it should be played, and how it should sound on your composition.
As a conductor, you can succeed or fail. In the latter, it will always be your fault, not the musician's nor the instrument's.
As with its musical counterpart, software composing is an art. An art that is surely dying. True software composition is getting lost behind agile development in some part. The real culpable are today's accessible tools and source-code snippets, which give fast and tricky results, but keep clients happy and quiet.
Software developers are beginning to look like a young man with a laptop and a loop software. I prefer a real musician with knowledge and background on real music. And that knows how to play at least one instrument (programming from scratch). Also, he should at least know how to read music (UML?)
