11–20 of 285 posts
It is a good idea to discuss with stakeholders, at a high level, why things _seem_ to take long, but I find that works best as a conversation. No one wants a tome like this in their inbox.
Part 4: learn to bill by the day and never again have to worry about justifying how long a simple-sounding code change took to make.
So would you bundle up a series of these into a day? Or just assume the client is cool with this taking a day? I believe you're also assuming you're servicing a client whose got a lot of budget to blow on a lot of small changes.
The best clients have more money than time and will pay you well to make their problems disappear. They pay you to think about the software for them, so they can spend their valuable time thinking about the business instead.
I'm not a dev, but this feels like arguing with a strawman. There are really customers who complain that a change to their codebase took a single day to implement? I would be utterly thrilled if I could get a vendor to turn around anything that quickly
It's not. I make the same complaint about developers I manage and it's so prevalent across the industry, I'm surprised you think it could be fiction. Of course, in large companies with a glut of process, making a change on a production system without testing is basically unthinkable. The reality is that most businesses have nothing more than production to work with.
People STOP saying things like this, when they are berated and/or overwhelmed and/or discouraged by details, as outlined in this letter...enough times.
Interesting fact: I worked on DrLaura.com's forum website in the late 90's when the naked college photos of her came out. They constantly were deleting posts and threads regarding the photos. Then, they ROUTINELY deleted entire forums. I put 7! popup warnings in front of this action, and the owners kept complaining that the moderators were doing it "accidentally" too often.
Never underestimate the tenacity and willful blindness of customers.
Too much protest here. I feel you'd be eventually judged on those numbers as well. Are you a time & materials shop? The fact is that you either start a clock when you start working on something and stop it when it's done or you have standard times that things should take (like an auto shop does.) If you're working efficiently, you can tell your client that you work efficiently and this is simply how long the change t…
* Document the customer request
* Investigate the customer request
* Create and document the requirement
* Assign the task
* Switch current context
* Deploy a dev environment
* Make the change
* Submit the change to QC
* Test the change
* Deploy the change
* Clean up dev environment
* Document the change
* Bill the customer
Ideally, you would encourage the customer to bundle multiple requests, so that most of the tasks could be shared among them. However, if they insist that they need it now, then they need to pay accordingly.
This story seems like it could be solved with improved up-front communication.
What gets me is that software has been a mainstay of modern business for _at least_ 30 years. And this whole time, every single professional software developer has been telling every single non-software developer the exact same thing, over and over: this takes longer to do than you think. If, say, 80% of developers were knocking things out, problem free, in an hour or two and the other 20% were hanging back like a 50…
Sure I can fire off that one line change and tell you it's done. But, does it work? Is it right? Do you care?
Typically this sub-par work is done by inexpensive outsourced development shops being managed by a client rep without the capacity to see through the lies until the project goes sideways in the future. The developers who rushed the work are paid and out of the picture and never have to fix the problem or touch that code again, so they don't care.
I do not think that is a good email for discussing a single, small feature. No client is going to want to read it. It's too long and detailed (1855 words!) and will probably only _increase_ their frustration. It is a good idea to discuss with stakeholders, at a high level, why things _seem_ to take long, but I find that works best as a conversation. No one wants a tome like this in their inbox.
There are some 2D conversations that are necessary. Dates, times, places. That sort of thing.
This is solidly 3D communication. It needs to absolutely be face to face. Otherwise the receiving person on that e-mail will (a) not read it, and (b) take it as a passive aggressive way to get out of work.
Oh, and (c) look at the length and complete unnecessary detail of that email that should be a meeting as another reason to accuse you of wasting time.
Yet they end people's careers and throw people in prison. People with nothing, trying to make the world better and get through the day.
Maybe stop saying how great you are while you burn through other people's lives like firewood with eyes, and start making their failures your failures.
Too much protest here. I feel you'd be eventually judged on those numbers as well. Are you a time & materials shop? The fact is that you either start a clock when you start working on something and stop it when it's done or you have standard times that things should take (like an auto shop does.) If you're working efficiently, you can tell your client that you work efficiently and this is simply how long the change t…
I don't think four hours is unreasonable for any type of shop (with 4-8 being CYA estimating). One or more resources likely have to do most of the steps below. * Document the customer request * Investigate the customer request * Create and document the requirement * Assign the task * Switch current context * Deploy a dev environment * Make the change * Submit the change to QC * Test the change * Deploy the change * C…
A better letter if you wanted to write one would be about the benefits you provide and the completeness of your work. I wouldn't even mention the time it takes.
What gets me is that software has been a mainstay of modern business for _at least_ 30 years. And this whole time, every single professional software developer has been telling every single non-software developer the exact same thing, over and over: this takes longer to do than you think. If, say, 80% of developers were knocking things out, problem free, in an hour or two and the other 20% were hanging back like a 50…
Inexperienced software engineers are less expensive, so you can hire more for your payroll budget. These juniors tend to think "yeah, that sounds pretty straightforward. I can do that in a week." It actually takes two months. It takes experience to estimate even nearly correctly. And MBAs love to buy some less expensive, less experienced engineers with their money.
You're better off avoiding getting to this point in the first place. Maintain a good relationship with cooperative clients and they won't (usually) complain, because they value your work. You should fire uncooperative clients and let them be someone else's headache, when possible.
Adding a little more detail to line items in invoices helps a lot too. "Fix bug report #493" should usually be, "Investigate report of incorrect discount calculation (#493), modify 1 file, review code, deploy to test, test for regressions (all tests passed), deploy to production."
It seems dumb and repetitive to us, but one of those descriptions looks like 4 hours' work to the person approving the invoice, and the other doesn't.