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

251–260 of 285 posts

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

#251

Post by bo1024 »

unreal37 wrote: post #110

I worked in software development within companies for 20+ years. The "why does it take so long" conversation has come up a lot. So on one hand, I see the argument. Simply opening unknown code, and making a change no matter how small, is a risky game. You need to research the impacts, test, and walk slowly through a deployment you haven'y done in ages. I totally get that. But I also see the other side. Why DOES it tak…

Very much agree -- this is a good chance to step back and ask how software practices can improve. It feels like we are a long way from optimal.

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

#252

Post by bobf »

jen729w wrote: post #219
thanatropism wrote: post #95

Earlier quoted context omitted.

> . 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. Most of these look like MBA problems. That said, maybe more experienced coders should be doing MBAs (which isn't just about attending classes but about networking, acquiring a wide…

My boss/friend just sat (passed) his PMP [0] exam and was talking to me about it as he learned. The main thing that I learned is that the amount of time they say 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 a…

Not that it's the best or only methodology to project planning in a given scenario, company, or industry, but I do think there's significant value in PMP training. I completed the PMP exam in 2012 after being encouraged by a coworker, and I see it as both useful and cheap enough to suggest it to most software/hardware developers.

Learning and applying "how to plan a project" has pretty universal career relevance. I suggest 30-40 hours of study time, and it's around ~$600 to buy the book, take the exam, etc.

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

#253

Post by jrochkind1 »

4ntonius8lock wrote: post #174
thanatropism wrote: post #95

Earlier quoted context omitted.

> . 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. Most of these look like MBA problems. That said, maybe more experienced coders should be doing MBAs (which isn't just about attending classes but about networking, acquiring a wide…

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 feature", they should be explaining what their actual needs are, what they need to get out of the software and why. And how important it is to them, or even what their "budget" for it is.

And a technical designer (who could be a developer who has some design skills perhaps by experience, or a designer who understands the tech) _designs a solution_.

This requires someone(s) on the "development" side who can do needs/requirements analysis leading design (ie, "UX"). And it requires the stakeholders to trust that the capacity is there, and that it will turn all right if they don't try to micromanage the feature -- not just "all right", it'll be SO MUCH BETTER.

This works so well when the organization staffs itself to make it possible and the people in charge allow it to happen, that it seems kind of insane that so few organizations do so.

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

#254

Post by ken »

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…

Is this unique to software?

Our shiny new tunnel took 3 years longer than planned. Our new aircraft are being accused of crashing due to engineering shortcuts to get them in the air faster. A tower crane fell across one of our main streets, killing 4 people, so even if that building was on schedule before, it's sure not going to be now.

Is there an industry which can complete all projects on-time and on-budget, with no catastrophes? I'd love to see it.

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

#255

Post by zebraflask »

adanto6840 wrote: post #54
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…

I've been a stakeholder in many a "rewrite is the only way forward" projects, though I have almost never actually advocated/voted for a "from-scratch" rewrite. I obviously say this having none of your domain-specific context -- so grain of salt -- but, in my experience, a total 'scratch' rewrite is rarely the right answer. Furthermore, it's often nearly impossible to even be able to ascertain the 'right answer' until…

Late to the thread, but just to chime in, briefly - I would agree unless the underlying platform has been deprecated.

If we're talking about something in Java that could be better, in the abstract, but it still works, agreed: it might not be worth the effort to redo. Java isn't going anywhere, and versioning differences aren't always critical.

If we're talking about deprecated front end frameworks that no longer have any LTS (Angular 1 comes to mind), moving over to a framework that does have LTS is a pretty smart move, if the code or app is that important and valuable.

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

#257

Post by robbiemitchell »

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…

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, working closely with designers (visual, UX, etc.)

Excellent companies figure out how to deploy these types of thinkers -- with appropriate mandate -- throughout the organization.

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

#258

Post by drieddust »

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…

In my opinion based on limited experience, this is happening because of unrealistic expectations set oy weak CIOs who doesn't have a spine to stand tall. Most CIOs usually leave in less than 3 years so promising moon and delivering Mariana trench is not a problem.

IT is just glorified technicians who should live in basement. Business is not willing to share power with IT. This is unwritten class system.

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

#259

Post by WheelsAtLarge »

Software programming and maintenance is mainly a mind game. The change requestor won't see you taking out a bunch of tools to get ready and they won't see you make the changes. It's hard for them to see why changes take the time they take. Also the time it takes to modify code is relative to the codebase, your understanding of it and the changes needed. I've had situation's when I've made changes in minutes but other changes have taken days. There's no way to standardize code change. Other professions can set a time on changes because there's been plenty of past data that can be referenced.

So given this, it is reasonable for requestors to feel like a change should be immediate because it seems simple relative to the way they themselves make changes when they need to. They are trying to use their past experience to come up with the time it should take to make a small change. So many things seem easy when you don't have the right experience.

The only way to counter this is to define very specifically why it will take a day vs whatever time they think it should take to make the changes. Even then it's a hard sell since the requestor will feel that a lot of what you are doing is a waste of time which in their mind equals a waste of money since time is money in business. This is how things have been, are, and will be.

I think part of a programmers training should include how to deal with customers since we all have had to deal with this situation and will continue to do so. It's part of being a programmer for hire.

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

#260

Post by bartread »

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.)

It's many years since I read this but I seem to remember the original impetus for agile was an internal software development team having a mix of longer term goals, and then lots of reactive work/support. Possibly the latter making up the majority.

It was a way to bring some sense of order to what was chaos: new requests coming in all the time, work being dropped partway through to deal with the new requests, little progress on any front.

I think agile works really well in this kind of context by bringing in a sense of discipline and keeping new work at bay until the beginning of the next cycle[1]. It can also help to keep teams delivery focussed in other contexts but, key point, does not obviate the need for additional planning outside the sprint/iteration framework.

The problem really occurs when people treat agile as sufficient on its own, or as the one project management tool to rule them all. Total nightmare, especially with multiple teams involved.

[1] How workable this is in practice is open to question: I can tell you it's not always a great approach in an environment where client projects typically last a few days and on time delivery has been known to depend on a critical bug fix for a legacy codebase. Especially problematic when requests come in either during the launch phase, because there's usually a fairly hard window, or during the reporting phase, because there's a delivery deadline looming.

Post reply on HN