Posted in: Java Article
Better code
One perspective is the one of a
developer. The developer in almost every medium-to-big organization, and
in quite a lot of small ones too, is pretty much disconnected with
product management/product ownership part of a project. It means that
they have very little-to-no knowledge what actually should be built.
Of course being a developer I can, and
should, share my concerns about usefulness of building specific features
but it’s unlikely I have enough information to judge such situations
correctly in many cases. By the way, even when I’m right and this darn
feature shouldn’t be built odds are that it’ll be built anyway because a
client says so. Sounds stupid? Sure, it does! Does it make the client
change their minds? Not very often.
If you’ve ever worked on one of those big
contracts where everything is (allegedly) specified upfront and no one
on a client’s side is willing to change anything because of internal
politics, you exactly know what I’m talking about. If you haven’t, well,
damn you, you lucky bastard.
So it might be a great idea not to build a
feature but developers either don’t have enough knowledge to be aware
of the fact or aren’t allowed to skip the feature anyway. In this case a
better thing to do is to focus on building better code, not less code,
because one can hardly say what meaningful less is.
Less code
The other perspective is the one of
product management folks, however this specific role is called in your
org. For them, their first and main focus should be on building less
code. Yes, product owners, product managers, etc. Yes, less code. And
yes, I do know they don’t write code. It still should be their main
goal.
You see, this is the place where
meaningful decisions about not building features can be made. Product
folks should know what adds value and what doesn’t. What’s more, they
are usually better suited to start such discussions with clients,
whenever needed. After all, it is so common that clients want, and pay
for, unnecessary features and useless code.
Organizational-wise you get more value,
or less waste, focusing on building less code. Given that you’re free to
work on both: better code and less code across the organization, it
would likely be wiser to choose the latter. At the same time efficiency
of your efforts depends much on the part of the organization you work
with and, locally, it may be a much better choice to focus quality of
code and not quantity of code as an issue to tackle.
So if I could choose what kind of
superhero posters are in rooms of my people I’d go with Peter Drucker
for product folks and Bob Martin for developers.
Source: blog.jelastic