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

151–160 of 285 posts

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

#151

Post by dllthomas »

collyw wrote: post #127
bluGill wrote: post #91

Earlier quoted context omitted.

In my experience it takes months of looking at existing code before you see the good architecture under the superficial mess. In other words, work in the current code for at least a year before proposing a re-write. Source code older the the application doesn't mean much as a statement - any good process will build off a CI system which only takes old source code. The question is how different is the application the…

Sometimes it's completely obvious that a design decision is flawed.

And when that's true, the design decision in question is often flawed.

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

#152

Post by majkinetor »

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…

Definition of Done (DoD) does not exist. It is whatever stakeholder needs it to be. Stakeholder might be delusional or not, its your thing to educate or if impossible, avoid working in toxic conditions that future will bring.

Everything is a feature:

- Automatic tests, a feature. You can buy it if you want or you can accept accidental bugs any time even for stuff that worked before, or even complete meltdown. You don't have to buy them (I personally usually stop working here as this is professionally unacceptable for me, there are tones of sub standard shops that can do this) but accept warnings and give written stuff about it so I can later just ignore your anger with full confidence.

- CI/CD - you can buy it, means we are agile and fast, we do 20 deployments a day vs 2 per week where some may fail due to insulin spike at the moment. Maybe you don't want it, and snail speed is acceptable for timeframe/budget or is the least evil.

- Epic docs - you can have them or not, again, it will determine how many people you will eventually have in the help desk team, the local IT team, the perceived quality of the system, etc...

- Metrics - yes, we can make nice dashboards and you can know FIRST when anybody gets unknown exception or CPU goes higher then 90% but maybe you don't care or don't have a budget and maybe we will spend time doing wrong things.... because we don't know how often are features used...

- Full auditing - maybe you need this 10 years back in full detail for legal reason, or NOT because you don't give a damn about it as you plan to sell it in 3. Your decision.

and so on and on...

Everything is a feature. I wont accept work without some features - I can be realistic if needed but we need to mutually understand and agree what it means for the system and have that written down on public place (for example company ticketing system).

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

#153

Post by cutenewt »

gilbetron wrote: post #125
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…

Three months ago I found myself in yet another discussion with a PM about time estimation. I gave him an analogy I use for non-developers, where you try to estimate how long it will take to pack a kitchen into boxes for moving, the catch, I said, is that there's a significant chance each time you open one of the cupboards or drawers there might be a whole other kitchen or even house behind it. He responded with, "wel…

I've always wondered why we don't provide estimates with a low, median, high scenario. It'd create a lot less disappointment and more accuracy.

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

#154

Post by dllthomas »

ma2rten wrote: post #99
avgDev wrote: post #86

Earlier quoted context omitted.

This is impossible in my case, the source code is outdated. We do not have the source code of the project, which we run in production. The dev lost it. I have tried working with the source code but it has many bugs and it appears to be two years out of date. This leaves us with an application only in its current state with no way of making any changes. I may be able to extract pieces of information, reuse some stored…

If it's language that has byte-code like java or .net you might be able to decompile the production binary.

Even if it's not, decompilation might be useful. What I'd try is decompiling both the running version and the build of the available source code, and see if the diff is informative.

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

#155

Post by vincnetas »

hinkley wrote: post #133
dsfyu404ed wrote: post #49

Earlier quoted context omitted.

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…

There was some CivE professor that people liked to quote who talked about how he had no qualms flunking people from his classes because a degree in Civil Engineering was a license to kill. If you let dumbasses through the system, they will build a pedestrian bridge in a hotel lobby that fails and kills a hundred people at a party.

For those who didn't catch the reference : Hyatt Regency Walkway Collapse

https://www.youtube.com/watch?v=VnvGwFegbC8

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

#157

Post by Retric »

noego wrote: post #40
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…

On the flip side, I've seen far too many teams move at the speed of molasses, for reasons unrelated to the intrinsic complexity of the problem. Bureaucracy, analysis paralysis, no automated testing, accidental complexity, tech debt, poor retention of experienced developers, poor compensation resulting in sub-par hires, insufficient training and mentoring for new hires etc etc. I wouldn't be so quick to assume that ev…

That’s irreverent as each estimation is based on that team and it’s situation. If I am going to spend 20 hours a week stuck in meetings that’s going to impact my estimates.

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

#158

Post by supernova87a »

Well, despite all the protestations that the letter tries to surface, some of which are legitimate -- sometimes it really is:

"We did not design our system to make simple changes simple, and are now paying the price for it in the gap of we can deliver versus what our customers intuitively believe and should expect as response time for simple changes."

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

#159

Post by megablast »

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…

> And this whole time, every single professional software developer has been telling every single non-software developer the exact same thing, over and over

What? No, not at all.

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

#160

Post by Consultant32452 »

cutenewt wrote: post #153
gilbetron wrote: post #125

Earlier quoted context omitted.

Three months ago I found myself in yet another discussion with a PM about time estimation. I gave him an analogy I use for non-developers, where you try to estimate how long it will take to pack a kitchen into boxes for moving, the catch, I said, is that there's a significant chance each time you open one of the cupboards or drawers there might be a whole other kitchen or even house behind it. He responded with, "wel…

I've always wondered why we don't provide estimates with a low, median, high scenario. It'd create a lot less disappointment and more accuracy.

Depending on the PM I've found giving a confidence level on an estimate to be helpful. For example on a task I've done a million times I might estimate that it will take me 1 hour with 95% confidence. Other tasks I might estimate at 2 weeks with 50% confidence, same task 3 weeks at 85% confidence. As with all things communication, the audience matters and it's incumbent on the speaker to communicate in a way the audience can understand. So that might not work with everyone.

Some of it I think is also personal confidence. If I tell someone it'll take me two weeks, I never budge unless new information becomes available. If you budge, you are welcoming being pressured/bullied into working overtime and/or delivering poor quality all the time to meet infinite demands. Also, we must accept that most customers are willing to accept lower quality/higher risk than we want to deliver. In this case what's important is to state the risks as plainly as possible and set boundaries on what you're willing to do before those risks come back at you.

Post reply on HN