Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear Client, Here’s Why That Change Took So Long

simplethread.com

Post reply on HN
Print view View original

41–50 of 285 posts

Re: Dear Client, Here’s Why That Change Took So Long

#41

Post by avgDev »

bfdm wrote: post #15
commandlinefan wrote: post #10

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…

There is a small subset of devs that will rush and get the work "done" in the underallocated time. The catch is in, of course, the Definition of Done. This is why we spend time aligning teams on exactly this. 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 cl…

Spot on.

I was 1st SE at the company I am at now. Previous applications were developed by outside contractors. I tried making some changes to that code base and found massive issues. Source code was older than the compiled application. Massive methods that were 1k+ lines long. Business rules all over the place in IF statements. Barely any documentation/comments. Only way forward is complete rewrite.

I'm a relatively fresh SE, but I read books/research good practices because I'm trying to avoid major mistakes. Also, it is hard to explain to people who even know some code, how difficult it is to make what seems like a simple form.

At this point I would refuse to work without time for unit testing/refactoring/research.

Interestingly, few days ago I made a very minor change in app I developed straight out of school. App had 0 unit testing and minimal integration testing. It created a bug, because I allowed the specs to change weekly and I just coded it without thinking. Therefore, many lessons were learned that day.

Re: Dear Client, Here’s Why That Change Took So Long

#42

Post by dfjhdkjfhsdkf »

dsp1234 wrote: post #31
commandlinefan wrote: post #10

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…

This isn't all on the non-developers. I've walked into two rooms this week, which contained several senior developers, and when I asked them about non-functional requirements, they had to ask what they were, and why they were important. I've also seen teams where the Defintion of Done doesn't include any steps at all towards deployment. Done is when someone approves the pull request. Not surprisingly, it takes longer…

I agree with your comment about senior devs. it seems as devs climb the ladder many get a superiority complex where they could do things quickly and others cannot.

I was once a tech lead of a team where the architect had been berating and criticizing a team member for weeks over something he thought should take a day.

I suggested he should take over and complete it. It took him weeks to complete.

Re: Dear Client, Here’s Why That Change Took So Long

#43

Post by raiflip »

ghostly_s wrote: post #26
raiflip wrote: post #24

It seems like most of the comments here either didn't read or missed the point of the article. Yes, this is a simple change. Yes, pushing a fix out in a day is actually pretty fast. But the author using a simple example to illustrate a point. Better than taking a complex example that takes 5 paragraphs to explain. Moreover you can easily extrapolate all the parameters in the article for complex examples. The primary…

I read the whole thing, and if the author was trying to use this as a simple example to illustrator a more general point, they did not communicate that effectively.

I thought the following line: "Below we have a letter that we have written variations of numerous times over the years. " made it clear that the letter is not real, and is therefore a semi-fictional example.

Re: Dear Client, Here’s Why That Change Took So Long

#44

Post by VBprogrammer »

dsp1234 wrote: post #31
commandlinefan wrote: post #10

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…

This isn't all on the non-developers. I've walked into two rooms this week, which contained several senior developers, and when I asked them about non-functional requirements, they had to ask what they were, and why they were important. I've also seen teams where the Defintion of Done doesn't include any steps at all towards deployment. Done is when someone approves the pull request. Not surprisingly, it takes longer…

To be fair; non-functional requirements as a separate entity are pretty much wank.

If you need a line in a document to tell you that exposing privileged information to the outside world is a bad idea, or that you should make sure the solution you are designing has a reasonable chance of servicing the expected load then you probably shouldn't be a developer.

The last time I seen explicit non-functional requirements the had something like "the solution should have a 99.99% uptime." I realised that our down time for releases (old school I know) was more than that and promptly ignored them.

Re: Dear Client, Here’s Why That Change Took So Long

#45

Post by jmilloy »

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.

Re: Dear Client, Here’s Why That Change Took So Long

#46

Post by te_platt »

My last two projects have been for the military and a medical device. The example here seems so wonderfully simple (even as an example of how much has to happen on a simple change). Add in all the process/design/QA/validation documents that need to be created -> passed off -> executed -> recorded and you are at much longer than a day.

Re: Dear Client, Here’s Why That Change Took So Long

#47

Post by Udik »

commandlinefan wrote: post #10

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…

I disagree. Sometimes a task requires more time than someone with no knowledge of the system would expect; sometimes it can take much less. I always thought that a big part of my job is to make tomorrow's changes less expensive than today's. If things are constantly costing more than expected, there is a problem.

Re: Dear Client, Here’s Why That Change Took So Long

#48

Post by bobm_kite9 »

Our internal model of the world is always simpler than the world itself (otherwise it wouldn't be a model).

This whole article is just saying "Dear client, here's why your model is insufficient".

Which is a much nicer email to write than "Dear client, here's why my model was insufficient". Which is what happens when the estimates go south

Re: Dear Client, Here’s Why That Change Took So Long

#49

Post by dsfyu404ed »

plausibilities wrote: post #29
bfdm wrote: post #15

Earlier quoted context omitted.

There is a small subset of devs that will rush and get the work "done" in the underallocated time. The catch is in, of course, the Definition of Done. This is why we spend time aligning teams on exactly this. 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 cl…

Handyman Contractor mentality vs Civil Engineer mentality in a nutshell Unfortunately not everyone cares about resilience and certain performance thresholds when it comes to construction, especially when budgets become involved. Some customers will are happy to cheap out for a hack-job remodel in the hopes that they can flip their home and run off before the bagholder realizes they got a lemon.

The handyman spends 20min thinking about how to solve the problem.

The civil engineer spends 20min thinking about how to solve the problem and 20-days making sure there's no way whoever signs his paycheck is going to be told by a court to pay out a bunch of money if something goes sideways.

An professional engineer is basically just a lawyer for the laws of physics. You're not paying for his ability to come up with a solution. Anyone can read the books and do that. You're paying for the fact that other people take that solution seriously.

Re: Dear Client, Here’s Why That Change Took So Long

#50

Post by jmilloy »

bobm_kite9 wrote: post #48

Our internal model of the world is always simpler than the world itself (otherwise it wouldn't be a model). This whole article is just saying "Dear client, here's why your model is insufficient". Which is a much nicer email to write than "Dear client, here's why my model was insufficient". Which is what happens when the estimates go south

I'd almost argue that, in the example, the clients model wasn't insufficient. If you want to include "implement automated testing" in a small feature request without telling your clien, then your client is probably right to be surprised!
Post reply on HN