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

121–130 of 285 posts

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

#121

Post by kolinko »

avgDev wrote: post #102
bluGill wrote: post #92

Earlier quoted context omitted.

At least you have something. You need to tell your boss that all features in the last 2 years need to be rewritten from scratch, with no lessons learned to speed up the effort, but that is still faster than starting over (particularly if the boss can say some things didn't turn out useful).

Would you take this approach even if the framework is outdated? Part of rewrite is to switch to a newer framework and make general improvements in maintainability, reliability and speed.

Yes. By the way - „Working effectively with legacy code”.

https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...

If you start from scratch you may bump into the same edge cases that the original writers bumped into, and end up with a code that is not much better than the original - even in the original is 2 years out of date.

I’m sure there were cases when writing from scratch was a good call, but I don’t remember hearing about it.

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

#122

Post by DonHopkins »

shaftway wrote: post #27
delinka wrote: post #19

Earlier quoted context omitted.

You're missing a critical part of the equation: the inexperienced software engineer. 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 experie…

Or even worse, they actually do knock it out way faster than expected, but it's buggy and unmaintainable. I was that inexperienced software engineer once. At the time a grizzled veteran tried to drop a knowledge bomb on me and said "A good programmer can write about 14 lines of code per day". It took me a really long time to figure out that he had mis-quoted something. It should have been "A good programmer only writ…

You should also get credit for the number of lines of code you read every day!

Some days you read pages and pages of code, but don't write a single line.

However, that makes it possible to figure out just the right 14 lines of code to write the next day, by reusing instead of duplicating code that's already there.

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

#123

Post by kevan »

SkyBelow wrote: post #87
dsp1234 wrote: post #31

Earlier quoted context omitted.

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…

>when I asked them about non-functional requirements, they had to ask what they were, and why they were important. Based on my own experience with NFRs, these are perfectly reasonable questions.

We're missing a lot of context about this situation to tell if anyone was being unreasonable. A reminder for everyone: unless you're all in on waterfall with complete specs, user stories are placeholders for a conversation. Talk to each other and assume good intent on all sides until proven otherwise. You'll have a much more enjoyable work experience than if you dig in and make things adversarial.

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

#124

Post by hinkley »

sneak wrote: post #76
noego wrote: post #40

Earlier quoted context omitted.

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…

The real trick is being able to tell the difference between a normally slow process and a pathologically slow process, on non-trivial scales. I’m 20+ years in and I’m just getting a handle on it in the last 5 years or so. Meanwhile, I see non-software people putting their complete trust in people with less than half my experience, and getting burned.

Limited Work in Progress tries to address this. The longer a task takes the more scrutiny it gets from hopefully sympathetic individuals. If you are chasing your tail, after a week or two someone who understands what's going on will unwind you and set you up to complete the task.

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

#125

Post by gilbetron »

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, "well, we just have to figure out which doors have kitchens behind them, that's all!"

But during this discussion, I could feel the weight of the countless times I had already had a similar discussion in the past and it was heavy on my soul. Seriously, it feels like we've made no progress at times.

Even here, at HN, I've several times brought up the paper "Large limits in software estimation" and been downvoted as not getting it.

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

#126

Post by ww520 »

reallydude wrote: post #13
ghostly_s wrote: post #6

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

> I'm not a dev, but this feels like arguing with a strawman. 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…

Interring story. 7 warning dialogs were funny. I guess they were under so much stress to delete the nuke pictures that their mind automatically filtered out any obstacle.

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

#127

Post by collyw »

bluGill wrote: post #91
avgDev wrote: post #41

Earlier quoted context omitted.

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…

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.

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

#128

Post by hinkley »

irq11 wrote: post #80
noego wrote: post #40

Earlier quoted context omitted.

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…

I’m dealing with this right now. A team that is downright arrogant about reducing their well-padded schedule, taking months to do a job that should take weeks, at most. Getting them to do anything is like pulling teeth, and accompanied with lots of arrogant lectures about how hard it is to estimate, how you can’t rush quality, and so on. It’s mostly bullshit. This team has historical reasons for their bloated schedul…

That knife cuts both ways. I am fundamentally a clever lazy person. I'm always looking for ways to reduce the amount of accidental complexity I have to do, and reduce the number of trivial interruptions I get by documenting the situation a little better every time someone asks me about it, until the rate drops below my pain threshold.

If it weren't for schedules I'd have no defense at all for 'wasting time' on something that saves each of my teammates an hour of pain per week. (I've had a lot of shitty managers. Stuff like this shouldn't need a defense).

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

#129

Post by [deleted] »

VBprogrammer wrote: post #44
dsp1234 wrote: post #31

Earlier quoted context omitted.

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 th…

[deleted]

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

#130

Post by yebyen »

> we always include time for writing automated tests in our estimates. It can slow down initial development, but it greatly improves the efficiency of operating and maintaining a software system. It isn’t until a system grows that you truly start to feel the pain of not having tests, and by that point it can be a monumental task to work tests back into the system

Not only this, but also: I've recently come to understand the idea that allocating enough time for writing unit tests and integration tests, tends to uncover design issues. If a test is taking longer to write than it seems like it should, or if a particular method or bit of functionality seems harder to test than it was to write, that is a signal that you may have a design issue!

Writing the automated tests will help you find out when you have written some code that stinks, if you know what to look for and have the time to step back and think about it. It's called "Red/Green/Refactor" for a reason, it's not "Red/Green/Red/Green/Red/Green" – if your estimates only allocate enough time to write the feature and nominally prove that it works, you're missing a critical part of the TDD pattern and you're not getting nearly as much long-term value out of your tests as you could.

If you don't write automated tests at all, it's even worse, because those design issues will only show themselves when it's time to make a change, and your bad design is now standing in the way, preventing you from iterating quickly when you really need it.

Post reply on HN