3 ms·

Say a business needs some web dashboards, you write them in a way that should be clean and maintainable, and has documentation for the next person to come in an

Say a business needs some web dashboards, you write them in a way that should be clean and maintainable, and has documentation for the next person to come in and help if needed later. They like what you did so ask for more of your help. They could decide to change at any time but like working with you and how you get things done, so keep going with the contract. I don't see how that could be seen as bad. You are helping the business, they are happy, paying, and you've even made it so if they wanted to switch it could be done in the easiest possible way. Did I miss something you'd be concerned about?

ergothus 7y ago
I see nothing concerning in what you've described, except that they are totally at your mercy for whether you are delivering what you describe. EVERYONE will say that the code is clean, maintainable, and has documentation that is meaningful for the next programmer to come along. Not everyone will be lying about that, and if I made it sound that way, my apologies. But if the next programmer comes along and says the code is a mess and poorly documented, the company is STILL not sure what's true. Is this next programmer the one with an issue? Was the original not stating the truth? Are both fine and this is a philosophical difference of approach? You can ask around...but you have no real way to judge the comments you get, and they have all the incentives to create misleading info. There's a power imbalance. I'm not saying consultancy is evil, and I'm not saying the power imbalance is avoidable, but in the context of the article - I'm not a big fan of encouraging the _furtherance_ of such a power imbalance, because once you get in, there's very little means of getting out.
- jupiter90000 7y ago
  You make a good point, and I don't disagree there are possible downsides. To be fair, some of the details you described could be issues with in-house employees as well, imho (folks/teams claiming clean/maintainable code when it's not, wanting to seem necessary, having the power to claim what the team is doing is right and good for business without business knowing any better, etc).

ergothus 7y ago

I see nothing concerning in what you've described, except that they are totally at your mercy for whether you are delivering what you describe. EVERYONE will say that the code is clean, maintainable, and has documentation that is meaningful for the next programmer to come along. Not everyone will be lying about that, and if I made it sound that way, my apologies. But if the next programmer comes along and says the code is a mess and poorly documented, the company is STILL not sure what's true. Is this next programmer the one with an issue? Was the original not stating the truth? Are both fine and this is a philosophical difference of approach? You can ask around...but you have no real way to judge the comments you get, and they have all the incentives to create misleading info. There's a power imbalance. I'm not saying consultancy is evil, and I'm not saying the power imbalance is avoidable, but in the context of the article - I'm not a big fan of encouraging the _furtherance_ of such a power imbalance, because once you get in, there's very little means of getting out.

jupiter90000 7y ago
You make a good point, and I don't disagree there are possible downsides. To be fair, some of the details you described could be issues with in-house employees as well, imho (folks/teams claiming clean/maintainable code when it's not, wanting to seem necessary, having the power to claim what the team is doing is right and good for business without business knowing any better, etc).