What is a developer's responsibility when a customer asks for a quick and dirty solution? Should they listen to the customer and take the short cut because, after all, they are paying the bill? Should they instead always do what is technically the "best" option in their opinion? Or is there a middle road that should be taken?
James Shore in Our Professional Responsibility gives a brief history of the customer/developer balance:
In the bad old days of waterfall development, programmers would figure out requirements, create a design, and then implement the design in the way that was most technically convenient. Programmers were king. Plans were created entirely by programmers. Or the programmers' Big Boss set a deadline--perhaps motivated by political pressures, or by romanticized memories of what he could program over a Jolt-fueled weekend--and programmers scrambled to meet it.*
*Yes, I'm over-simplifying a complex situation. I'm Allowed.
Agile development reacted to this, saying, "Hey! Wait a second! This isn't working! We're not delivering value to our customers." The planning game restores balance to the equation. Customers are in charge of value; programmers are in charge of cost.
Some agile teams have let the pendulum swing too far. They've abdicated responsibility. They say, "The customers are in charge! We have to do whatever they say."
That's taking it too far.
In his opinion, developers should not be in charge, but at the same time, it is their responsibility to develop quality code. Always.
And when someone says, "Can't you take a shortcut and get this done faster?" look them straight in the eye and say "No." "No, we can't do that without hurting our schedule. But I can help you find ways to simplify features so we can finish faster."
Reg Braithwaite, in What I admire about professions like Engineering and Medicine, suggests that it may not be a bad idea to listen to the customer if they want a quick and dirty solution in some cases:
Now, I don’t agree that you should refuse to slap together quick and dirty code that will be hell to maintain when told to do so. Whether that is a good idea or not is a judgment call. I choose to write software as cleanly as I know how within the constraints of my relationship with my client or employer. I choose to evangelize my judgment on the matter strongly.
But I don’t think I have the right to out-and-out refuse to do so when my employer or client insists. They suffer the consequences of software that is difficult to maintain, so they and they alone have the last word on the subject.
Where he draws the line is not quality, but ethics.
In the case of software development, if I am asked to develop software that is insecure and places private user data at risk, I will make the personal choice of saying no.
Of course, I do not have the protection of the law. If I am fired for doing so, I have no recourse. I can’t even collect unemployment benefits, I will be deemed to have been dismissed for cause. Programmers work at will, which means that you must value your ethics very highly if you are to place your livelihood on the line for it.
Robert Martin (Uncle Bob), in Business software is Messy and Ugly, suggests that quick and dirty solutions are the wrong decision. In response to quote from one of his client's managers "Business software is messy and ugly":
No, it’s not! The rules can be complicated, arbitrary, and ad-hoc; but the code does not need to be messy and ugly. Indeed, the more arbitrary, complex, and ad-hoc the business rules are, the cleaner the code needs to be. You cannot manage the mess of the rules if they are contained by another mess! The only way to get a handle on the messy rules is to express them in the cleanest and clearest code you can.
Finally, in a previous InfoQ article, Refactoring is a Necessary Waste, many of the user comments revolved on when to put time into refactor code and when you should not do so.
So, what are your thoughts on the true responsibility of a developer? Should they "just say no" when it comes to shortcuts? Should they listen to the customer requests? Or, should they be flexible but hone in things that affect the customer and hold fast to their values and ethics?
Community comments
"What" versus "how"
by Susan Davis,
Re: "What" versus "how"
by James Shore,
Re:
by Reg Braithwaite,
Re: "What" versus "how"
by James Shore,
Debt Must be Managed!
by Dave Rooney,
Re:"What" versus "how"
by Susan Davis,
The definition of quality....
by Amr Elssamadisy,
Re: The definition of quality....
by Javid Jamae,
If the customer isn't in charge, than who is?
by Amr Elssamadisy,
Re: If the customer isn't in charge, than who is?
by James Shore,
Re: If the customer isn't in charge, than who is?
by Dave Rooney,
Re: If the customer isn't in charge, than who is?
by James Shore,
Re: If the customer isn't in charge, than who is?
by Javid Jamae,
Re: If the customer isn't in charge, than who is?
by Dave Rooney,
Re: If the customer isn't in charge, than who is?
by Javid Jamae,
Re: If the customer isn't in charge, than who is?
by Dave Rooney,
Re: If the customer isn't in charge, than who is?
by Javid Jamae,
Who is the Expert?
by Paul W. Homer,
Consensus?
by Amr Elssamadisy,
"What" versus "how"
by Susan Davis,
Your message is awaiting moderation. Thank you for participating in the discussion.
The missing insight here is that "shortcuts" aren't. And while the customer is in charge of what the team is to build, the team itself is responsible for how it gets there... and any contract worth signing needs to preserve the team's ability to deliver a system in the fastest and lowest-cost way possible. Running up technical debt increases the cost of a given project, and getting the customer to understand that is essential.
Re: "What" versus "how"
by James Shore,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think Susan's hit it exactly right. Taking shortcuts and incurring technical debt may feel faster, but it's not. It immediately hurts your productivity. Customers get to choose what goes into the software, but programmers have to be able to choose the most cost-effective way to do so. And the most cost-effective way I know is to keep code quality high at all times.
Re:
by Reg Braithwaite,
Your message is awaiting moderation. Thank you for participating in the discussion.
You pointed out that "Running up technical debt increases the cost of a given project, and getting the customer to understand that is essential." I agree, but what happens when the client understands that but still wants you to go into debt?
In that case, I believe we have to decide whether the project will succeed or fail. If it will fail, I want to say no, to walk away. But if we are arguing between a mediocre project and a good project, I believe we must allow the client to make the final call.
Re: "What" versus "how"
by James Shore,
Your message is awaiting moderation. Thank you for participating in the discussion.
(Note to InfoQ: the subject line isn't being preserved on replies.)
Reg, you make some interesting points in your essay. I also think you're addressing a broader point than I am, which confuses the issue a bit.
So let's look at the specific case of deliberately incurring technical debt in order to meet a deadline. More specifically, we've got an agile team that has provided an estimate for a story, but now is being pressured by its on-site customers or product owner to take shortcuts in order to reduce that estimate.
The mistake I see teams make, and the mistake I think you're making, is to assume that the on-site customers and product owners are in charge. On an agile team, that shouldn't be true. It's a team, not a heirarchy. The whole team should be working together to create a good plan. If that's not happening--if anybody, programmers or customers, is bullying or making unilateral decisions--then something is wrong.
The team, not the customers, not the programmers, but the team is responsible for figuring out how to best meet organizational goals.
Now, if executive sponsor who's funding the project says, "thou shalt use punch cards and COBOL," or anything similarly silly*, that's fine. That's what you do, after informing her of the ramifications of her decision (and starting your job search). But on-site customers and product owners are not executive sponsors. They're part of the team. They're an equal voice, not the last word.
PS: I'm the first to admit that it's sometimes appropriate to incur technical debt to meet a deadline. There are consequences--serious consequences--and it's not something to do lightly. Again, the decision to incur technical debt should be a team decision, one that's made with eyes open and that balances business rewards with technical costs and risks.
*PPS: To be totally fair, I imagine there are times when punch cards and COBOL might actually be appropriate. Maybe.
Debt Must be Managed!
by Dave Rooney,
Your message is awaiting moderation. Thank you for participating in the discussion.
How many of us who own homes would be able to do so without incurring some debt? Yes, it costs considerably more in the long run to finance the house, but if that's the only way you can possibly afford to buy it then you need to live with the interest costs. This can apply to code as well. Some debt is OK as long as everyone - Customer, Developers, Managers - understands that they are incurring debt that MUST be repaid at some point.
However, this analogy works only for a traditional mortgage. I think there's a nice parallel to be drawn between unpaid technical debt and the current crisis in the U.S. with the sub-prime mortgage industry. A mortgage with lower payments based on the speculated future value of a house may have seemed like a good idea at the time, but people are now losing their homes and savings as a result.
Dave Rooney
Mayford Technologies
Re:"What" versus "how"
by Susan Davis,
Your message is awaiting moderation. Thank you for participating in the discussion.
[W]hat happens when the client understands that but still wants you to go into debt?
That depends: how was the contract written? Will the customer be the one paying the increased cost, or is it a fixed price contract where the burden would fall on me? In the latter case (assuming that I was foolish or desperate enough to sign such a thing), the answer is no (possibly even "hell, no!"); in the former case, the Law of Toyota applies.
I'd still lay out what the impact horizon was for the customer, and try to get them to realize that they're acting irrationally in that case, and I might think hard about taking further work from them, but if we're getting paid for the extra trouble, and I've gone as far as I can to dissuade the customer, then they get what they ask for. That's assuming, of course, that I'm not working in some domain with significant potential consequences for the public -- avionics, medical devices, reactor controls, railroad switches, or so forth.
The definition of quality....
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
What exactly is under negotiation between developer and customer? Is it:
1) The extra time to write tests?
2) The extra time to refactor code that is under requirements?
3) The extra time to make the developer feel a warm-fuzzy about the beauty of the code?
I don't know about others, but I have rarely, if ever, had a problem with a customer that after a discussion about what will happen that they said " don't write tests". Because, in reality, after becoming proficient at TDD, I've become a faster developer.
Now, I have had customers request that we not put in extra features - whether it is architecture/infrastructure upfront, logging, security, etc... because they had to have it done. After explaining the costs of putting in the work afterwards when the need arises, I'm more than happy to take their lead and they understand the tradeoffs.
So, maybe I've been lucky, but after a good long talk with the customer, we've always found some scope to drop to meet the deadlines/cost. That scope sometimes was a customer feature, and sometimes was a generalization or 'large refactoring' that I put off until later (and carrying a technical debt).
If the customer isn't in charge, than who is?
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
I find the statement 'the customer is not in charge' a little strange.
Someone has to be driving the car, someone has to be deciding which features and functionality to address first must be.
It is either the customer or the developer (or maybe the tester?)
Can someone tell me if the customer isn't driving than who should drive instead?
Re: The definition of quality....
by Javid Jamae,
Your message is awaiting moderation. Thank you for participating in the discussion.
I've blogged about the effects of not refactoring and accumulating technical debt.
I look at quality as internal or external. The internal quality is the readability and reusability of the code, the number of tests, the amount of cohesion and coupling in the design, etc. The external quality is the usefulness and richness of the externally visible parts of the system (logging, UI, documentation, installer). I generally look at internal quality as non-negotiable and external quality as part of my acceptance criteria for a story, and thereby part of the scope (and therefore controlled by the product owner).
This is often called the depth of the scope. I typically have a conversation with a product owner about reducing the depth of the scope before it ever gets to the point of desperation where they are asking a team to cut into their internal quality. An iteration planning meeting is usually where this happens. Nine times out of ten, this is an adequate enough conversation. For me personally (knock on wood) its been more like ten times out of ten. :)
That being said, I've been on teams where we decided to not do any composite (or big) refactorings for a particular sprint. These are things that might swallow about half a day.
I've heard of teams doing varying lengths of iterations where the insert shorter iterations in for paying back technical debt. For example 2 weeks, 2 weeks, 1 week cleanup. I don't personally think this sounds like a good model, but I won't dog it until I try it.
Re: If the customer isn't in charge, than who is?
by James Shore,
Your message is awaiting moderation. Thank you for participating in the discussion.
Amr said:
Assuming a cross-functional agile team consisting of programmers, on-site customers, and testers--and that is our goal, I hope--then the whole team is in charge. The team is responsible for creating the best plans to achieve the project vision.
That requires taking advantage of differences in team members' expertise. In practice, on-site customers are expert in business value, so they set priorities. Programmers are expert in technical costs, so they set estimates, and they should include the cost of keeping development speed high in those estimates. The two pieces of information together, along with the team's measured velocity, creates the plan. Neither customers nor programmers are in charge... they both are, jointly.
Some people describe this as "customers driving," which is fine, but don't misinterpret that to mean that the on-site customers are in charge or that programmers have to do whatever the on-site customers say. The whole team is in charge. As soon as one group or another hijacks that shared responsibility, the project suffers.
Who is the Expert?
by Paul W. Homer,
Your message is awaiting moderation. Thank you for participating in the discussion.
If a 'customer' comes to me as the 'expert' on building software tools, I expect that they will take my 'advice' seriously. They may be the expert when it comes to the problem domain, but if I am the technical lead, I am there because I have the knowledge and background to build software tools reliably. Sometimes we need to follow short-term goals for political reasons, but we always want to angle for the long-term where ever possible (unless we are planning on quiting :-). If it is an issue of sending a junior programmer off for a couple of days, so long as it is not a regular event it might be ok, but generally where there is smoke, there is fire. If there is even a hint of longer term consequences, then I've always been under the belief that "anything done, should be done well". Why waste lots of time in little chunks.
If my advice is not taken seriously, then it is probably time to move onto something new. If I don't know or can't decide, then I probably shouldn't be the technical lead (yet). If I'm not the lead, then it is not my problem, and I need to respect the lead's choice (but I might still pay attention just to learn how to handle the situation).
As software developers we are professionals, which implies that we have some unspoken degree of professionalism that we have to live up to. We really should know when to properly make short-term vs. long-term trade offs, and understand the full consequences of choosing either approach. Because it is usually dependent on the situation it can be very hard to quantify. Practical experience is the best teacher.
Re: If the customer isn't in charge, than who is?
by Dave Rooney,
Your message is awaiting moderation. Thank you for participating in the discussion.
Agreed, however I believe that there still needs to be one person overseeing the whole team. You and I have both written about Product Managers and I believe they add value.
I see the Product Manager role in this context to be not unlike the 'captain' on an airliner. Quite often the first officer does the flying, but the captain is ultimately in charge. Their work is always collaborative but when push comes to shove the captain's word is final (for better or for worse). In all but a utopian world, I believe that someone with the last word on decisions is necessary. A Product Manager who is able to balance both business and technical needs can address many of the issues we've brought up with requirements for dealing with technical debt while still delivering business value.
Dave Rooney
Mayford Technologies
Re: If the customer isn't in charge, than who is?
by James Shore,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hmm... I agree that product managers are important and valuable, but I see them as leading the on-site customers, not the whole team. What you're describing sounds more like the "Chief Engineer" role at Toyota that the Poppendiecks describe--somebody who combines product expertise with technical expertise.
I can see the appeal of a Chief Engineer. I haven't yet worked with a team who had somebody in that role, but I'm looking forward to when I can. I wouldn't want to put the product manager in charge in most cases for two reasons--one, because I think a self-organizing team can make better decisions in most cases, and two, because I've seen this structure has led to technical debt and reduced ability to deliver in several organizations.
The closest analogy to Chief Engineer might be the XP coach, but in my opinion a good XP coach does not lead; he enables the team to self-organize, encouraging people to take the lead in their areas of expertise and looking for opportunities to cede responsibility to the team.
Consensus?
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
What I've found in the Agile field is a diversity of opinion in everything from a developer's responsibility, to whether refactoring is a necessary waste, to if private methods are good/bad and should be tested or not....
If I were a new comer to Agile or looking from the outside, I think I would be very concerned that even the experts don't agree.
From the inside, I think that is one of the best things about Agile, that we recognize that there is no one solution.
Hmmm.....
Re: If the customer isn't in charge, than who is?
by Javid Jamae,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have a problem with these types of statements. You are making sweeping generalizations about what will work universally across all projects. I would prefer hearing something like "I've seen X and Y projects fail, and I believe it was because we didn't have somebody in this 'I am the god of all decisions' role. Here are my reasons why..."
Every project, team, organization has a different culture. To say that the practice of self-organization and collaborative (consensus-based) decision making won't work except in a "utopian world" is flat out false. It can and has worked on teams that I and others have been on.
Don't undermine the viability of the practice because you haven't experienced it successfully, or because you don't see how it will fit in to your team or organization.
Re: If the customer isn't in charge, than who is?
by Dave Rooney,
Your message is awaiting moderation. Thank you for participating in the discussion.
Fair enough, and apologies if I came across as arrogant. Perhaps I could have phrased my thoughts better by referring to leadership as opposed to a specific role. In my experience, the best leaders have been the ones who know when to build a consensus and when to just make a decision to be able to move forward within the overall vision of the project. People who are averse to confrontation to not exhibit the latter characteristic - while everyone thinks they are a great person, the aren't necessarily great leaders. Similarly, people who don't try to build a consensus aren't effective leaders for very long, if at all.
I'm quite certain that it's possible to have a fully self-organized team. It's also possible to implement true communism. Both cases don't scale well (though it isn't impossible), and in all cases you are still beholden to the personalities involved. It takes a very unique set of people from both the business and technical world to be able to work together effectively in a truly self-organizing fashion.
Please don't make assumptions. I have been an 'official' agile practitioner since 2000, and used most of the practices and certainly the principles since the late 1980's.
Dave Rooney
Mayford Technologies
Re: If the customer isn't in charge, than who is?
by Javid Jamae,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yes great leaders are good at building consensus. But consider the situation where a group is trying to make a decision and one person has a difficult time committing to that decision (let's say a story estimate during planning poker). If the "power wielding leader" makes a "decision to move forward" before the team comes to a consensus they are nullifying that persons concern. This does not solve problems, it hides them. Consensus forces important discussions and decisions to happen. When people start learning that their opinion isn't important because somebody has the power to override it because they disagree and have the power to override, then the team gets demoralized and people start just "going along" and being "team players".
In my mind, there is the difference between a leader and a manager. A manager is put in a position of power where he can override his subordinates decisions and ignore their concerns if he so wishes. A leader cannot make decisions for the group, he can only lead the group to make decisions. A leader does not need to be assigned a position / role, he can naturally emerge based on the situation or team.
I didn't think we'd see a derivative of Godwin's Law emerge so soon. Next we'll be flipping the bozo bit. :)
Agility is all about self-organization and consensus. What would collaborative code ownership be if we had the "one final word" on design? What would story estimation be if we had the "one final word" on estimates? What would retrospectives be if we had "one final word" on issues and actionable items? What would "whole team" be if we had "one final word" on any important decision?
I agree that it would be unfeasible to get consensus with a team of let's say 15 or 20 people. Honestly, I've never seen any organizational structure that helps scale a single team past 8-10 developers. I've personally never developed software on a team that has more than 8-10 developers, and have found teams larger than that very uncommon in my consulting work. I personally prefer team sizes of 4-6 developers and find that self-organization can work great in these cases. It is not difficult to get consensus between 5-6 people who work closely and share the same vision and goals. But it is dangerous when you don't get consensus.
I like to think of it this way: if you hire six people, put them on a team together, and pay them on the order of half a million dollars a year to work together, then you'd better damn well trust their opinions when one of them raises a flag. If you don't, then why did you hire them? Why build an organization on an accountability model using a command and control structure when you can build it on responsibility model with a self-organizing structure?
Multiple teams that collaborate together can also self-organize with techniques such as scrum-of-scrums. I took a Certified Scrum Master course with Craig Larman , who is a big advocate of Scrum and self-organization and has worked with many large organizations and large teams to implement these techniques. In this course, he talked about some of his experiences scaling self-organization to very large development efforts in very well known companies. He has written a book on the topic (though I haven't read it yet).
Re: If the customer isn't in charge, than who is?
by Dave Rooney,
Your message is awaiting moderation. Thank you for participating in the discussion.
Javid, this has nothing to do with a fallacious argument. Communism as originally intended would be great with everyone taking care of everyone else and working for the common good. The problems with communism and software development start when you implement it with people. ;)
With regards to your comments about Scrum, I also agree that it can be scaled. Does Scrum not have, however, a Product Owner?
Please understand that I do believe in self-organization. Again, the best teams on which I've worked have been self-organized, albeit with strong leadership. I'm a fervent advocate for smaller over larger teams, as light a process as you can possibly get away with, co-location with the people for whom the software is being built, and a technical team composed of Specializing Generalists.
My experience in working from startups with a headcount in the single digits to multi-billion dollar projects with teams in 3 digits has been that a single, strong leader is a huge asset. See my earlier post for what I believe (and have experienced) are the best attributes of a leader.
Dave Rooney
Mayford Technologies
Re: If the customer isn't in charge, than who is?
by Javid Jamae,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yes, but I've never seen anything in the Scrum literature that says that the Product Owner has the right to make internal quality tradeoffs. The product owner makes external product decisions, the development team makes internal product decisions, and everybody works together to make process decisions. IMHO, the technical team has a right (and professional responsibility) to maintain high internal quality and nobody can and should take that right away from them.
Yes, and being a strong leader is an ability not an authority. I think the real strength comes in knowing how to facilitate and elicit participation, not necessarily in knowing how to make quick logical decisions. I've come to this realization not only through my professional career, but also through being a father and a husband.
Just to let you know Dave, I truly respect your opinion, which you've come to through years of experience. But, I disagree with you on a few things. Let's see what we agree and disagree on:
We'll have to agree to disagree on what self-organization means. You believe that in a self-organized team somebody can have the final word and by my definition self-organization implies a consensus model where no one person has the final word.
You believe that consensus is difficult to come to, and I agree that it can be difficult for certain situations. But, I believe in the value of the conversations that emerge out of that difficulty.
You (I'm guessing) believe that because consensus can be difficult to come to, it introduces inefficiency. You therefore use this as justification for the existence of a "final-word leader". I believe that overriding disagreement and nullifying individual concern for the sake of productivity can backfire and ultimately create a less productive atmosphere. This is because people become less likely to debate or bring up concerns when they know the "final-word leader" will override them.
You believe that the success of software hinges on people and personalities. I totally agree, and that's why I would want buy-in from all the people on the team (with no decision overriding) so that everybody feels involved.
You believe that teams should have strong leaders who can bring people to consensus. I agree and think that if they are actually good enough to bring people to a consensus then there is no need for assigning them "final word" power.
You (I gather) think that leaders should be assigned. I don't think they have to be assigned or have any assigned power above and beyond anybody else. That being said, a self-organized team may elect to put somebody in a decision making position for certain decisions and should have the power to remove them if they feel they need to.