The Software Composer

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?)

Reinventing the wheel

There's a common saying in software development: "don't reinvent the wheel".

This saying means you shouldn't start coding from scratch something that has already been done and you can use to save time and effort. The wheel basically is a method of function, or a set of them, that is needed as part of the software you're developing.

This philosophy is not a bad thing in itself, it means well, it wants you to avoid extra work. But it's awfully abused and misinterpreted.

Here are the only two cases when you can use this philosophy:

1. You have to know how to make the wheel in the first place! Most people avoiding reinventing the wheel, do it out of laziness and lack of proper programming knowledge. You should at least be able to visualize how you would construct the wheel, with a fair amount of implementation detail.
2. You have already made similar wheels in the past. From experience, you know how to do it, and you could do it, but you're behind schedule, and this borrowed wheel won't alter your software's customization and flexibility. 

Reinventing the wheel is rarely a bad thing in software development. It has many advantages:

• The wheel is 100% yours to customize, alter, destroy, make rectangular, etc.
• Deriving from that idea, the wheel you're using is not attached to some third-party license or user-agreement.
• You can isolate your wheel and make it available for others, giving that they fit in one of the two cases established above.
• Reinventing the wheel, in most cases, implies doing it your way, with your style, your choice of design, and it's a perfect fit for your software
• Reinventing the wheel proves you can do it, and shows you're capable. You would be surprise how many ignorant programmers use this "reinventing the wheel" philosophy to hide the fact that they have absolutely no clue on how to do it. If you're a manager, be wary of those!