The Pressure to Deliver Value to the Business
Dave Schinkel 8/14/2014 03:54:00 AM Craftsmanship
ohhhhhhh I love this phrase
because it's one I've heard myself before myself:
"I know you’re capable of doing this."
This blog post from 8th light called Honesty Under Pressure turned on a light in my head and got me going because I can totally relate to these types of comments I might get as a developer.
This kind of phrase gives me the image of a manager pounding down on that Staples "It's easy" button.
Lets be honest, that phrase is a sales pitch and command to cut corners. It usually translates directly to "I want you to cut corners, we don't have to be perfect, we can skip core principals that we feel only has to be done half the time, and so lets get this out the door and provide business value" type of nonsense. If you hear that too often, it demotivates you if you are a developer who cares about speed AND quality. And it can drive a team culture away from quality.
"Capable" should never correlate to JUST speed. It's about being capable by doing it WELL. We are capable of doing anything. We are capable of rushing and creating poor quality, or we can be capable of going fast with quality. Sometimes you need to slow down instead of speeding up, as hard as it is for that person to swallow.
We want to be fast with quality at all times. For some developers, it's in their very nature to care, and to be passionate about providing quality at all times in addition to speed. Quality includes refactoring frequently when you see opportunities to make code better, driving code by test (TDD) where you can, and adding code coverage after where you need to.
There are times when during a sprint that you discover things. You discover things about your code when you do both TDD and also refactoring. Both those bring to light a LOT. In fact today, we realized a lot when we started to refactor and move stuff into methods and then out to a new class to keep things simple. We learned that this refactoring that took us a few minutes now allowed us to add code coverage that was not possible before, because that code was in one huge method, or a bunch of unrelated code was all in one large class breaking the the Single Responsibility Principal.
There are times that we are told to throw in hacks rather than take that 1-5 minutes to refactor. "You're capable of pasting in slop or skipping code coverage, or capable of skipping refactoring frequently such ignoring the fact that you just saw several cases in the code you just touched where abstracting some of that code out into new methods, a new class, or whatever it is". I don't accept that as a way to code.
I'd much rather be capable of doing it well AND fast rather than doing it too fast just to put a smile on my boss, PM, and the business's face.
Going back to that blog post from 8th light. It's true. Sometimes you have to look in your boss, colleague, or PM's face and be honest. That no, this story is not going to make it. Sure it could make it if I copy and paste for you for this last tidbit for this story. But guess what, I'm not going to copy and paste code everywhere, sorry, It may take a few more hours. Because I care about quality and maybe we had some unexpected delays, or something took longer than we had estimated.
Don't be scared to do that. Communicate it as early as you can, but take pride in the fact that you didn't just rush it to get it out the door, you slowed down and made sure that quality is always the outcome.
If quality is what you want out of your developers, don't say sentences like that. And Developers if you are ones who care about quality, don't accept that kind of statement.
My definition of value in software development includes speed and quality which translates to a lot of things including maintainability, readability, speed, test-ability, and simplicity of code. I do not cut off the later, I do not cut off quality.
Simplicity comes from looking at your code every small step of the way (I do this a lot when I TDD), refactoring along the way, and keeping things simple. Simplicity is when you name methods, classes, and variables to make total sense in that they imply exactly what they do. Simple is adhering to the SOLID principals, especially Single Responsiblity. Refactoring allows you to keep things simple as well and reusable.
These are all attributes that make up value to the business, your team, and ultimately your family because you can go home at the end of the day because you don't work in a mess, you work in code that has been crafted by developers who care about the code they write and the code they write for others to consume or extend.
Contrary to status quo, is not as "relative" as a term as you may think. Software Craftsmanship is also not as relative term as some think. Some people will try to minimize the term Quality and Craftsmanship just to get you to speed up too often and too much.
Quality can be measured
How so? well some examples are by # of bugs, % of of code coverage, and usability (speed, simplicity, navigation, etc.) of your application as a whole to other developers and end users who consume or use the application you write.
Use Tools and Defend Claims on Time
I use tools to make my life easier. For example ReSharper. I can prove that Visual Studio doesn't provide the same that ReSharper does and that it matters. I have become a much quicker programmer because of this tool.
Therefore when I refactor it's usually 2-3x as quick as someone who doesn't have a tool like ReSharper in many cases. So they end up pointing out that you took too much time moving some stuff out into a new class.
You know it didn't. Stand up to that and let them know. Correct them and tell them that hey, it did not take that amount of time because I use templates, or I use this tool or that.
Don't let someone dictate to you that you took too much time when they have no idea and were not there when you actually did that refactoring! How do they know?
Don't Feel Bad, Don't Worry, Keep Your Head Up
I'm not always the popular guy on some teams.
"Hey did you drive that with TDD or did you add code coverage to that existing code"
"Hey, lets move that set of code out into some methods, it's hard to read and it's doing way too much here"
"Hey lets break this method out now, not later"
"Hey what do you think about renaming that variable to make more sense"
Don't feel bad or Timid About Pushing for Quality
Explain the benefit the best you can, but don't let someone try to shut you up if you want to voice a concern around it.
Try not to drag out the conversation but certainly don't go run and hide under the rock because a particular teammate always likes to rush.
I can tell you that when I pair with those who care about quality, we have very very quick conversations throughout the day, every day. We might have 10-20 second conversations while we pair quite often. But that's good, because you are both striving to maintain quality around small units.
And I've noticed that when I pair with people who do not care enough about quality, the opposite happens usually. You're pressured to continually rush. And these are people who don't care about learning either. They don't care about having small conversations to gain the benefit of learning as well, one of the benefits of pairing. That's not the kind of pressure you want to have constantly on a team if you want a culture that drives quality in your organization. These kinds of devs belong in a culture that fits them, somewhere else if not willing to change.
Quality is Hard
First off it's both a people thing, and it's a code thing...balancing of each. It's hard to get people who are lazy in the bad sense if the word to care more about quality. And likewise, It's hard to learn to be a better communicator to help advocate quality and show benefits where you can. It's hard. But please don't be that developer who wants to always be be lazy in the bad sense of the term.
And each and every one of us should try to become better coder as well. I am always learning.
Always Strive to Get Better Driven by Quality
When you strive for Quality, you get better as a developer. When you do not strive for quality, you become a complacent developer.
Don't you want to continually learn and become a better developer? Let the goal of pursuing quality drive that.
Cutting Corners & Code Rot
Should we cut corners? Lets be realistic, sure we have to sometimes. But it's how many corners you are cutting, how often, and in what situations/reasons. Always look to refactor often in small amounts...never all at the end. Because when you keep your code simple, refactor often, you find that there are less corners to cut and when you do decide to cut corners, they're minimal.
Be careful about cutting corners. Some devs like to cut corners a lot. I think some devs feel good when they cut a lot of corners just because they were able to tell their boss it was done or that they can clock out at 5pm.
But ask yourself every time, is it going to make the code harder to deal with next time? Is it going to perform horribly? Can you read it? Every little corner you cut counts and as a whole these corners cut have a huge effect on the amount of code rot in your application. Too many corners cut can have the effect of forcing or persuading other developers to cut those corners too when they see that being done often.
No you don't always have to debate it with them but if you feel strongly that cutting a particular corner (as simple as it may be to them), might be bad for the code speak up. Have a constructive conversation around it. You'd be surprised, usually you learn something half the time and change your own mind half the time and even wrong sometimes!
Trade-Offs / Compromise
Yes there are trade-offs and compromises that you might have to make.
I'm not saying you need to be debating everything.
For example, maybe in a class you originally thought it would be better to create a bunch of overloaded methods instead of cramming all params into one method including optional params. Maybe you see the trade-off as making the decision to go a head and stuffing more params into a method even though you know it might make that method less desirable because you may have a bunch of if statements in it, more than you're usually comfortable with as a lot of logic usually means you're violating SRP and your method is doing too much. I made that trade-off recently with a collegue, even though inside it felt gross.
But just don't make trade-offs always a split decision without at least thinking about it. Don't let someone push you to skip your thoughts. I've seen that happen a lot. There are developers who will do that. They'll continually cut a ton of corners and not question even their own trade-off just because they're dancing around because they just care about speed only.
Dates are just Estimates
Don't let a hard date deter you from driving code based on quality. Yes we try to hit the dates we give don't get me wrong and we should try very hard to hit those dates always. However, don't let the hard date be the end all if you feel quality is not there.
We did not go to college just to come out of it, get a job, and then care only about codeing as fast as we as the ultimate factor of success.
We are not Part-Time Professionals
There is no "we can care about quality half the time and the other half can be copy and paste, or that 100 line method can just sit there, we don't need to break it up, that small 2 minute refactoring is just unnecessary and waste of time". There is no part-time quality. You either care about it at all times or you do not...period. That's why I see developers as black and white. There is no grey. And there should not be a grey.
We are professionals, not hackers. We deliver business value fast, but learn together and figure out how to do that with quality every step of the way as we code to deliver this ever so sacred term "value" to the business.
As professional developers, we should be learning from each other and expect quality from each other as developers at all times. If less experienced developers don't understand how to bake in quality code yet, help help them to when you see those places that can be made better.