Dear Client, Here’s Why That Change Took So Long • Hacker News Board

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

#261

Post by tracker1 » Wed, May 08, 2019, 7:29 AM UTC

stickfigure wrote: post #131

novaleaf wrote: post #101

Earlier quoted context omitted.

my own anicdata: Integrate a default proxy into our existing "choose proxy" workflow takes about 2 weeks, and I'm currently on my 3rd month of those 2 weeks :) Reasons for the delay: 1) Proxy is a stand-alone application. Needs it's own deployment and build configuration 2) Main app was running on Node 6.x. High time to upgrade to 10.x as 6.x LTS is running out. 3) Upgrade to 10.x breaks some modules we depend on (Go…

While all platforms have some measure of this phenomenon, the update treadmill problem does seem to be especially acute in the javascript ecosystem. I update Java dependencies maybe once a year; it's usually painless and incompatibilities are highlighted by the type system. If you let your JS dependences get stale by a few months, you're looking at hours or days of work. And that doesn't count the massive shifts in b…

I just spend maybe half a day a month updating everything to the latest and testing. There are the occasional gotchas, but it's not so bad... When you leave a codebase to rot for a few years, it doesn't surprise me that it's more painful.

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

#262

Post by Someone » Wed, May 08, 2019, 7:39 AM UTC

jen729w wrote: post #238

Buttons840 wrote: post #226

Earlier quoted context omitted.

> you need to spend planning a thing is waaaaaaaaay longer than we’ve ever spent planning a thing. Orders of magnitude longer. And you plan it multiple times over, with rounds of stakeholder engagement, rounds of risk analysis, rounds of breaking it down and analysing each component and figuring out what it is and how long it will take and what can go wrong and the dependencies and so on and so forth ... and then goi…

So I just said that in order to get a project planned properly you need to spend way more time planning it, and you literally said "yuck", let's use agile instead. Which is ... not planning it properly. And anyone wonders why we're in this situation? We dug this hole, kids. (And to be clear, I'm guilty . I'm not trying to be better than anyone. I am not! I'm just attempting to explain it.)

Agile works well for redecorating a house (“let’s paint the walls first, and worry about the couch later”), less so for building one. That requires more foresight, larger-scale planning, and writing things down.

With agile, building houses still somewhat works because people will do that planning in their heads. So, knowledge will end up _only_ in people’s heads, not even in everyone’s heads, and will deteriorate there, even if those people do not leave the project.

So, by the time it’s time to do a large-scale update to the house (add a room, update ventilation to modern standards), nobody knows where the ventilation ducts run, why one of them is so much larger, that there’s asbestos in the ceiling, etc.

And of course, some people try to use agile not for building houses, but for building apartment blocks.

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

#263

Post by repolfx » Wed, May 08, 2019, 9:22 AM UTC

jrochkind1 wrote: post #253

4ntonius8lock wrote: post #174

Earlier quoted context omitted.

As someone who has spent time as a project and product manager, I will say a lot of it comes down to a point of view that 'tech will make it happen'. Many times I've seen long time estimates for something, because C level was requesting "X feature". But when you sit down down with C level, and understand what they want to achieve with X feature, many times it is possible to sit down with tech and figure a way to get…

> because C level was requesting "X feature". But when you sit down down with C level, and understand what they want to achieve with X feature, many times it is possible to sit down with tech and figure a way to get what was wanted without the feature, generally by adapting some other request or feature. In the best functioning development organizations I have experienced or seen, nobody should be asking for "X featu…

Well, because stating needs and not implementations disempowers managers and means they're left with no feeling of grip. It makes it hard to imagine what you'll actually get and whether it'll be useful, which is scary. Plus, what people need is often so vague that literally anyone could have come up with it and it's embarrassingly obvious. If a manager goes to his tech team and says, "I need to make our business more efficient. Think of something!" then this may be the best way to get results because often the programmers understand the business as well as or better than the managers and they understand the codebase, but who would respect a manager who said that? It'd be Dilbert cartoons all over.

This is one reason why tech firms win. Their senior management are made of [former] engineers who are much more aligned with the workers around what implementations make sense.

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

#264

Post by repolfx » Wed, May 08, 2019, 9:45 AM UTC

Consultant32452 wrote: post #160

cutenewt wrote: post #153

Earlier quoted context omitted.

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

I think the problem there is that the uncertainty bounds can be massive. Almost every task will have the form:

"This task should take a day. But if the feature of the framework I plan to use turns out to be buggy, it might take a month. A bug is unlikely but not impossible, I handwave a guess at 10%."

This sort of estimate might be reasonable, or not, depending how fractal you want to get with the backup plan of a month of tasks which themselves have wide uncertainty estimates. But it's also quite useless for planning. You end up with a Gantt chart that says "this project might take 3 months, or 5 years", which helps nobody.

Hence #NoEstimates

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

#265

Post by arvinsim » Wed, May 08, 2019, 10:20 AM UTC

robbiemitchell wrote: post #257

jrochkind1 wrote: post #253

Earlier quoted context omitted.

> because C level was requesting "X feature". But when you sit down down with C level, and understand what they want to achieve with X feature, many times it is possible to sit down with tech and figure a way to get what was wanted without the feature, generally by adapting some other request or feature. In the best functioning development organizations I have experienced or seen, nobody should be asking for "X featu…

You just described product managers. They solicit needs from customers, support conversations, etc. and translate those into future development. They combine those needs into major product directions and balance them with an internal compass for where the companyw wants the product to be (i.e., what jobs they want to solve for which users.) They are technical people with an eye for how something should be built, work…

I am pretty sure that my Product Manager has no technical experience at all. And I assume that it's not mandatory for them.

If they are supposed to be technical, then we hired wrongly.

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

#266

Post by dkarl » Wed, May 08, 2019, 10:49 AM UTC

pjmlp wrote: post #207

dkarl wrote: post #194

Earlier quoted context omitted.

What's wrong about this is that from the client point of view, Definition of Done ends up depending on who they're talking to more than their situation. Hence the sibling comment of "Handyman Contractor mentality vs Civil Engineer mentality." It becomes a question of identity rather than a question of what the situation demands. I'm not sure how to fix this, but I don't think the problem is as bad in practice as it i…

We do. That is why any proper RFP answer already provides a broad overview how the problem would be tackled, and possible solutions to the described problem. Also why during the project development, at various delivery phases, artifacts like architecture diagrams, documentation and UAT from customer team take place.

It sounds like you're only selecting jobs that require the approach you're accustomed to, which is fine when you get to pick your jobs, but it isn't an option for internal dev teams that work on a product. The jobs come at whatever size they are. If the job is to change a word on a web page, there isn't going to be an architecture diagram, and UAT is going to mean someone reloaded the page and messaged "looks good, thanks!" to the developer.

For a consumer product with millions of users, there's probably a checklist of device platforms, screen sizes, browsers, and screen orientations to check that one-word change, but for a SaaS offering with less than 100k users, probably not.

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

#267

Post by bluGill » Wed, May 08, 2019, 12:20 PM UTC

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.

I disagree with the term obvious.

Sometimes it only seems completely obvious until you discover an unexpected constraint that the design decision address well. Sometimes those constraints are no longer a limiting factor and you can safely rethink the design, sometimes they are an elegant way to prevent a specific real problem and you shouldn't.

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

#268

Post by namelosw » Wed, May 08, 2019, 12:20 PM UTC

I work on a project consists of tens of devs that continuously delivered applications for almost a decade, and I joined this team 3 yrs ago. At some peaks, there were almost a hundred people. We still continuously deliver new features to the project every day.

We bill by hours as a lot of people suggest in this thread. Which works pretty well. We also have flexible iteration plans, the clients can prioritize any feature that is important to them. If a feature does not worth it, it will likely stay in backlog forever.

Most things are really smooth IMO, though explaining why technical stuff is costly/mandatory is really hard to deal with. Because both of us want the project to be an ever-green project, we need technical advancement, architectural extensibilities. It's so hard to even convince myself if I considered myself a non-technical person. Why do you need to split into services? Why things are not immediately synchronized after the splitting? Why do you need a job here, and what's a job exactly?

At the end of the day, it seems when you are convincing people about things they've no idea, you really need to be trusted -- just like you kind of trust doctor, and being suspicious about witch doctors. To achieve this, it seems better first to be business-focused and solving problems to build trust and reputation, as some kind of credits.

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

#269

Post by SkyBelow » Wed, May 08, 2019, 1:28 PM UTC

pjmlp wrote: post #212

SkyBelow wrote: post #196

Earlier quoted context omitted.

For me, it was more "These things you call NFRs, I do not understand the purpose of them, especially given how they are decided." Requirements like "The system must be secure.", "The system must not go down.", or "The system must not have performance issues." I'm lost as to what the purpose of such statements are as they don't let me know where real focus needs to be given. Not every system is mission critical and de…

The purpose of those statements are to uphold contracts and compensation clauses when things go wrong and end up in court due to refuse of payment for delivering broken software (which might be debatable if that was indeed the case).

See, that would make sense if it was something like 'our system must have 99.9% uptime'. But to say it cannot have any downtime, at the same time as our releases requiring us to take it down during the release, and at the same time the business contracts allowing for downtime for releases, means that the NFRs do not have any realistic requirements and are thus useless.

It's like saying mobile devices must be supported. Does that mean only top of the line recent releases? Does that mean 8 year old smartphones? Does that mean the internet browser on the Nintendo DS?

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

#270

Post by knightofmars » Wed, May 08, 2019, 1:29 PM UTC

drewolbrich wrote: post #70

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…

Even though the code you are interacting with appears awful, you may want to reconsider the rewrite strategy. This post may be helpful: https://www.joelonsoftware.com/2000/04/06/things-you-should-... Consider rewriting only a handful of small parts that are causing problems critical to the success of the product, and making small improvements to the rest of it as needed over time.

Don't take the Joel On Software article as gospel (not saying that anyone is). There are other models out there as well: https://medium.com/@herbcaudill/lessons-from-6-software-rewr...