Methodical selection
Software development has too many edges and it can be a completely different thing for two slightly different teams. Even within a single company, the methodology between teams might not be the same.
As it happens with programming languages, there’s no one size fits all. You get to know a programming language a lot better once you know how it’s compiled, loaded to memory and executed. This is what I’m trying to do with methodologies. Consider this as an introspection of my somewhat limited experience.`
In order to understand the nature of software development, what helped me was a comparison Albert Gil, a colleague from Happy Computing made between software products and hardware products. Hardware products are old, and it’s to be expected that with the years comes knowledge and expertise. Software is new, but spreads quickly. If evolution tells us something about this is that we’ll have some weird mutants before we can have a well defined specimen.
Same old, same old
Early on, people tried to apply hardware production chains to software. It was the most intuitive and logical way to do things. For hardware it’s actually the only way it can work, each step needs the previous one. Let’s take quick broad look at the stages.
- Have an idea
- Analyse what it solves
- Design the product
- Build the product
- See if it works
- Sell it
Sounds familiar?
Behold the waterfall software model. This is the one I learnt during my years in university. I actually thought that’s how all companies would be making software, because why would you not?
What you see is what you get
Giants in the industry are by definition the leading force. In the early years those were the ones making hardware. Therefore, they were the ones with means (money) to start making software. It’s a no brainer, they applied the methodology they knew to the products they didn’t.
And it worked! The waterfall methodology is a solid solution, easy to relate to for the stakeholders and producers. It is very convenient for them because they get a sense of the stage production is currently in. This methodology was the undisputed cornerstone of software development for quite some time.
Now let’s find the conflict in our story. Why would the solid Waterfall…well, fall? What contenders could it have? Who was upset about the status quo back there?
The artist
Ask Apple who’s more important when making the iPhone, is it the designers from California, or the assemblers from China?
Now ask the same question for a software product. Is the architect’s job more important than the programmer’s? I think this used to be the case. Programmers were understood as the workforce, the ones hitting the nails with a hammer. Does this mean programming is simpler? Maybe, at some point, it was. Now I think we can all agree it’s just a different task, but not necessarily a different job.
I remember wondering whether I wanted to be a programmer, the hardworking guy writing elegant and efficient code; or the architect/designer, wrapping my head around high level understanding of the program and the design patterns that could be used. That’s how I understood the profession worked, what I was taught.
Now I just thought of my job as developer, the guy doing software development whatever it takes. And I believe that’s what these roles have turned into.
A new contender
I believe it was the guys tired of hitting nails, who came up with this revolutionary idea of writing a manifesto. The Agile manifesto, which has shaped the recent years of development.
Newborn companies are famous for giving developers commodities, levelling the various roles in a project. Tech leads get their hands dirty with the team.
The key concept is treating development as a creative process, beyond labels and roles, new methodologies give somewhat more freedom to the developer to just code and deploy things that work.
Aftermath
I’m no-one to say which methodology is the best to stick to. Waterfall works, same as agile and many other flavours. Best advice is to focus on the task, make the team happy and make sure communication is solved.
What can I say, I’m quite okay with agile development. It gives me a comfortable pace of work and helps me tie business and technical ends together. Seeing there has been an evolution of methodologies, I also wonder what manifesto will hit the bell next.
The last one that caught my eye was, Programming, Motherfucker. Do you speak it?