A current (ok now its old) conversation on LinkedIn was the source for the first post of 2015. (Yes I’ve been slacking a bit).
While on vacation, I spent some thinking about the fact that many organizations have “Product” groups that are separate (read completely different organizational structure) from the “Technology” group. In fact, the only organizations where I have not seen this are the technology startups that I have been involved with.
I happened to bring up this point in the LinkedIn conversation only to be told the following:
Software Engineering – Build what product management tells you to build. Worry about predictability, quality, productivity and extensibility
Product Management – What should be build? What is the business case for it?
Really? Is that really what Software Engineering is about? Building what product management tells you to build? Could it be true? We shouldn’t care about what we’re actually delivering? I believe that such an opinion leaves a lot on the table and yet I’ve found it to be a common opinion in more than one organization. Ever heard this: “don’t ask why, just do it”! Unfortunately, statements like this reveal a complete lack in understanding of software engineering.
I won’t get into a discourse on software engineering as there are many institutions of repute (and Google) that can you help you out with that but I do want to point out an important aspect of software engineering that trained software engineers are very familiar with – requirements engineering. Requirements engineering is all about determining what problem needs to be (dis)solved and what outcome is desired. I realize that “requirements” is often a red word in Agile circles because of its literal application in many command and control type organizations. I mean, who hasn’t heard the “go read the requirements” reply before? But when you really think about it, you’ll see that Agile methods promote performing requirements engineering throughout the entire product development process.
So its my belief that software engineers need to understand “what should be built” and “the business case for it”. In fact, I’d suggest that it’s irresponsible not understanding why. Sure, there may be another group (for example product) focused on idea generation and problem identification but instead of walls between product and development, let’s have a mesh with ideas and information flowing both ways. It is product development afterall, isn’t it? Software engineers ultimately need to understand the problem to be able to deliver the best solution (they are capable of delivering).
As I pointed out here:
To get the “best” solution, it seems to work best IME when those delivering the solution understand “why” and the outcome desired. I have been told many times in the past to do X because it was needed but if I had understood “why” and the outcome, would have done X+ or maybe Y. A key component of software engineering is requirements engineering. Requirements engineering asks us to understand the problem.
So friends, don’t let friends tell you that software engineering is just about building what we are told to build. It’s more than that!