An interesting discussion (that might have happened):
I would rather students apply their effort to writing better code than to writing better comments.
But…
I would rather students apply their efforts to writing less code than writing “better” code.
Because…
There is nothing so useless as doing efficiently that which should not be done at all.
Having read this, one realization is that better code often means less code. I don’t think about lines of code exactly, or something similarly stupid, but in terms of meaningful code. However, argument for less code isn’t about making code as compact as possible, avoid redundancy, etc.
The argument is about not writing code at all whenever reasonable or possible.
Should we focus on deciding what should and what should not built instead of polishing our software development craft then?
Yes and no.
Yeah, I know. Exactly the kind of answer you expected, isn’t it? Anyway, you can’t answer this question meaningfully without a context.
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.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
13 comments… add one
Pawel, I wonder how a developer can call herself developer without domain knowledge. I’d call such a person programmer. Don’t get me wrong: there are situations where being a programmer is OK and is the only role that is expected of the coding folks.
As a developer and aspiring software craftsman I go with Bob and try to avoid coding as often as I can. I want to deeply understand what the business people really really want to be in the product. My happiest days are when I leave my office and the codebase is smaller than in the morning.
@Leider – I know great developers who fit your description — they are willing to know the domain, understand why they’re building stuff they’re building, etc. Now, how the heck a single developer can have a full picture of a project that takes 40 man years? Actually understanding the whole stuff in this kind of projects is usually full-time job for a few folks.
Then, there are a lot of situations where even if you understand and know that something shouldn’t be built you have very little or no power to change the decision that tells a team to develop the darn feature. What then? Should you start a fight? “This shouldn’t be built at all, so I refuse to write the code?” :)
Anyway, I’m with you on principles: as long as domain knowledge is available — use it. Learn the big picture. You will be able to make better everyday decisions or, if you can’t make your calls, at least give reasonable suggestions.
And if you happen to have knowledge and power to make your calls what is being built and what isn’t, well, use it, and use it wisely. My observation is that, in this case, you belong to a lucky fraction of a developer’s population. Most of folks out there aren’t even close to that.
Good points and completely agreed. – Your last sentence makes me feel sad. Don’t you think that developers should emancipate and try to get out of their silos? And isn’t it part of us lucky ones to help them grow?
@Leider – It wasn’t my goal to make you sad. It’s just an observation.
Anyway, I agree that, whenever possible, we should encourage developers (all people really) to leave their silos, leave their comfort zones and take a fresh look at things they do. What more, I believe that it would be valuable even in these projects where they won’t be able or allowed to make their calls in terms of what is built.
However, the question I asked myself before writing this post was whether this should be their main focus. I came to conclusion that they should become fans of Uncle Bob in the first place.
By the way, in terms of helping to move developers out of their silos, becoming better programmers is quite a strategy. From what I witness, following this path, they quickly become more self-aware and, eventually, either get more influence on product folks or leave to work for better-suited companies. Either way a win.
In other words, a choice from the title isn’t mutually exclusive. It’s just more a question of focusing more on one or the other end of scale.
Hi,
I don’t think code better or code less is a good title, because it is not a choice, you have to do both. However whether or not to do something is the decision that needs to occur first, and then you decide how to do it. There isn’t much point coding the best thing in the world, only to decide later you don’t need it, and throw it away. Or at least getting those decisions in the right order is a good idea.
As a developer in a medium to large organisation you might think it would be better to focus on what Uncle Bob etc are saying, but chances are all the effort you invest in advanced coding practices will go to waste. You probably won’t be allowed to use them. The architect will say “ok so here is the design you need to use, the architecture team has developed a framework, all you need to do is copy and paste these xml model files and change the details and ….”. You can’t even begin with TDD in that environment. Or HR will say, “No we only require c# and sql server. You are not allowed to use unit testing, dependancy injection, or FitNesse because it is hard enough to find developers as it is without requiring all those extra skills. And the works council won’t allow it anyway, as it is specified in the contracts what skills are expected.”
Eventually you will accept that, and do your best, but suffer from a lack of motivation because you don’t know what you are building or why, and you don’t even see if anyone ever appreciates your effort or not. So you will start fighting for more customer contact, and trying to understand what it is you are actually building and why. Someone might try and prevent this from happening, but a professional developer will feel compelled to do this. He will take part in the domain community. He will initiate informal contact with the stakeholders. He will contribute in planning meetings and provide feedback on the value or otherwise of various features.
Generally I think you probably either have a crappy old fashioned culture, which encourages both bad code, and wasteful features. Or a good modern culture which encourages the opposite. Rather than being a choice, they go together. It is not a dial that can be adjusted, do we optimise the product or the code, but what sort of mindset does the organisation have. The question is more one of, do employees have the freedom to make their own decisions and own the process, and thus help make sensible decisions on both the features and the code quality, or are they constrained by a management system (or their own lack of will in some cases) that disempowers and demotivates them?
As a developer, if either wasteful features, or bad code are an issue, I wouldn’t concentrate on fixing them directly, I would concentrate on improving the culture indirectly via improvements to the management system and organisational mindset. Not easy, but trying to improve either product management or even technical management without having the right cultural basis in place is ineffective.
Also regarding “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.”:
Source code, either reducing the amount or in general, shouldn’t be a goal at all of product people, and shouldn’t even be the main goal of software developers. That is the type of thinking that leads to the situation where wasteful code is produced. The focus should be on helping someone to realise value. The fact that specific problems can be solved with or without the support of computer software is secondary. There is always some reason why the software is being produced, and losing sight of that is dangerous.
@Kurt – I believe you’ve added a lot of depth to the discussion.
For one, I agree with what you describe as desirable developer’s attitude. Yes, I want them to do both: less code and better code. From what I witness, however, in many orgs there’s way more friction to do the former than the latter. In such case, my common sense advice would be to go where you get grease first.
Then I like your point that it’s not either-or choice (I never considered it like that; forgive the title) or even not a linear scale between one and the other. On some levels our actions push us on both ends and this is likely best what we can do.
Finally, I’m with you that general focus of every single person in a team should be on delivering value.
In ideal world I wouldn’t have anything to add. I don’t live in ideal world though. I see developers who can’t see the big picture, thus they can’t possibly say what exactly is useful and what is not. I see organizations that struggle to agree on what is and what isn’t useful with their clients. I see clients playing internal politics against projects’ success, let alone their usefulness. And, in many of these situations, I don’t see many chance to change everything, given that you’re just of developers.
Yes, there’s always an argument “either change your organization or change your organization” but if someone isn’t willing, for now, to take an extreme choice they might make use of guidance. The guidance adjusted to the way how their world looks like.
Btw: I like the idea that developers should improve management system and organizational culture. I just see it succeeding very, very rarely. Unlike improving one’s software development skills.
replace ‘or’ with ‘and’:)
I doubt that if it is at all possible for majority of developers to change directions even if the developers know what they are building. Many of those non-technical managers would not listen to developers at all. They just want to push whatever they want.. inconsistent UI and workflow no matter if it leads to messy and hacky code which is hard to maintain. They just don’t get it. And I think this is common situation for many developers, and under tight schedules and budget.. Better code? Less code? Hardly..
@Tae – One thing I din’t get. Is hacking crappy code faster? I mean, really?
I’ve seen many projects where little investment in code quality (because of tight schedules) made the project even later because of very long and very painful stabilization phase with lots and lots bug fixing. I’ve seen too many of these to believe that quick and dirty code is a feasible answer to tight deadlines.
And in terms of better code — how many managers in such situations pay attention to what exactly is in code on everyday basis? How many of them would tell you not to write tests, to use the first example from the top of my head?
And even if they do, well, just do it anyway and, eventually, ask forgiveness. It’s unlikely that you’re going to need it.
That is why personal project always escalate so quickly into features fests.
@Pawel: “Then, there are a lot of situations where even if you understand and know that something shouldn’t be built you have very little or no power to change the decision that tells a team to develop the darn feature. What then?”
The correct answer is to raise these concerns. One role that we should all embrace is consultant. We have domain knowledge of the technical side of things (as well as some of the *why* applications are built the way they are which bleeds into the business side) that every developer should feel is part of their role to bring to the discussion.
If the client considers that feedback and then says, “ok, but go ahead they way we originally planned,” then they’ve at least made an informed (albeit bad) decision. Not bringing up *why* a feature is a bad idea is simply shirking responsiblity (IMO).
@Scott – Well, I implicitly assumed that concerns were raised and dismissed in this case, as I agree this is the least everyone should do. I definitely don’t advise sitting silently and doing nothing, when you believe your team does useless work.
I’m also with you when it comes to addressing root cause of such attitude. It’s all about taking responsibility.
Yet it’s pretty common that, despite knowledge and responsibility, developers lack power to convince decision-makers. Even more common in bigger orgs.
Thanks for the post. For me the best developer would incorporate both less code and better code.
Less code is part of the better code ranging from code maintenance by another developer because you won’t work until you die coding in one organization anyway to code re-usability.