Hacker News Reader

Comment by jmilloy | Hacker News Reader

The idea is sound, but this letter is truly surprising to me. Instead of a succinct summary of what goes into the change, we get a long-winded narrative that reads to me as full of excuses. I think a more useful email would be a breakdown of the time actually spent, and a proposal for improvement, something closer to this (obviously sent after the feature has been deployed, and obviously including additional items for documentation, code review, whatever else takes time in your development process):

  Summary
   - 0.5 hours investigation and planning
   - 0.5 hours feature development
   - 4.5 hours manually testing
   - 0.5 hours deployment
   
  Proposal
   - 8 additional hours now adding automated testing

Obviously, depending on your client, they may prefer a more verbose format or need some more explanation, but probably 3-6 sentences at most.

View on HN

Pro-tip for anyone who needs to internally sell getting the automated testing in. Feel free to gently inflate the manual testing and deflate the automated testing numbers, and make it clear that the automated testing will reduce the cost of the next ticket.

Once a code base has decent test coverage the time it takes to add additional tests is pretty reasonable and most of that manual testing time goes away.

Do you think a housing contractor is "making excuses" when they apply the rationale requesting to take down a wall in the house by saying: 1) we need to investigate the condition 2) check if its load bearing 3) check if it runs electrical or plumbing 4) check if it is to code

No, they're telling you the rationale of what goes into making a change. I agree that this isn't something you should send to clients. But, even sending a summary to someone who invokes this question will ask the same thing for any item you summarize. The next question will be, "Why does it take 4.5 hours to manually test?"

So, explaining the rationale, at least once, will help the customer understand the process and could contest specific elements rather than trying to hide it in vagueness.

Really, I don't think that the developer is "making excuses" here. Which makes it all the more unfortunate that the letter as written sounds like excuses.

> The next question will be, "Why does it take 4.5 hours to manually test?"

I'm not sure it will. In my experience, clients are usually surprised about how long something takes not because they think specific tasks are taking too long, but because they aren't really aware of what the tasks are nor of their tradeoffs.

"You're right, it took longer than expected. I chose to spent some time setting up automated tests. That took extra time now, but will save much more time later."

I disagree with you. I don't think the article is "full of excuses." The details are essential to help non-developers understand why things take longer than expected, giving them a list of hours is not helping them anymore understand what goes on.

Agreed. This post is one long excuse.

If I was the client and you sent me this blog post as an answer to "why is it taking too long?", I'd fire you.

Because you spent more time writing the post than it'd take to update the code.

Reply on news.ycombinator.com