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

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

#271

Post by jrochkind1 » Wed, May 08, 2019, 3:06 PM UTC

repolfx wrote: post #263

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…

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…

That's why it's an actual skill to translate needs to implementation. It's not one most managers have either, is why when the managers just give you implementation it does not work.

The skill includes working with the stakeholders to develop actionable needs (not just "make our business more efficient"; the obvious place to go from there is, okay, what do we know about where the greatest bottlenecks/inefficiencies are now, if we don't know enough what can we do to learn?).

Also you don't just take needs and come back with a finished feature, you iterate with feedback from the stakeholders. The first iteration might just be a textual description of the feature, to make sure it makes sense to the manager/stakeholder.

It's a skill, and it involves building trust.

But translating needs to features that will succesfully meet those needs is not a skill most managers/stakeholders have either, is exactly why it doesn't work to just get detailed micro-managed implementation directions from managers/stakeholders. (Or customers!).

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

#272

Post by avgDev » Wed, May 08, 2019, 3:33 PM UTC

Drdrdrq wrote: post #235

avgDev wrote: post #167

Earlier quoted context omitted.

Good suggestion. I have decompiled the version in production. I will admit that reading it, is extremely frustrating as there are no objects and fields are named field1, field2, field3.

Still, you can compile + decompile the code you have, and compare that to decompiled production app. This might allow you to apply any cganges back to the code. Btw, it's not a dev who lost the code, it's the company and inadequate development process. It should never have been the single dev's responsibility to make backups.

Definitely did not mean to only blame the dev. The company knows that errors were made on both sides, hence why we are working on improving the process.

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

#273

Post by funkymike » Wed, May 08, 2019, 3:47 PM UTC

dfjhdkjfhsdkf wrote: post #42

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…

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.

I'm sure I still have far to go, but currently when I see someone quote a time frame for a change I am more concerned when it is short vs. seems too long. Especially when the dev is questioned and the estimate doesn't include time for documentation, deployment, etc.

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

#274

Post by dllthomas » Wed, May 08, 2019, 4:01 PM UTC

adanto6840 wrote: post #213

dllthomas wrote: post #88

Earlier quoted context omitted.

Also keep in mind that often the existing application is the only real artifact you have capturing all of the complexity and corner cases your rewrite will have to deal with.

This is a very good point and it's probably far more common than it is given credit for. Sometimes you manage to catch some of these early on, but often they aren't caught until later in the process -- at which point the cost for the change (and the impact on budget/timeline, and potentially even the very architecture you set out to fix!) is drastically higher . I've seen it happen a number of times where the 'spec'…

It's important that documentation be clear, discoverable, and up to date.

Code-as-documentation is best-in-class at staying up to date, when it comes to documenting what a system does and how. Often the relevant pieces are very discoverable as you're going to make a change. For other goals, it's much less discoverable. Clarity depends on both how the software is written and who the audience is.

Tests-as-documentation are arguably a special case of code-as-documentation. Outside of the case of well maintained tests-as-documentation, code-as-documentation often has a hard time expressing "why" and distinguishing between what has to be a certain way and what just happened to be that way.

It also has some trouble expressing aspiration - "we've decided it should be this way, but it's not yet".

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

#275

Post by repolfx » Wed, May 08, 2019, 8:33 PM UTC

rdiddly wrote: post #236

munk-a wrote: post #208

Earlier quoted context omitted.

I disagree, technical debt is a much more liquid quantity that can be easily paid off in as little or great a chunk as you wish. If you as a company offered to let everyone pay off tech debt with 10% of their time, but force it to be 10% on a daily basis you'll likely end up accumulating more debt - paying off monetary debt a little at a time by diverting x% of revenue to it is a particularly good way to handle debt…

So tech debt is harder to subdivide arbitrarily, I'll buy that. And it's harder to quantify in the first place, which seems to be one of the theses of this "dear client" letter.

Not only harder to quanitify. "Tech debt" is frequently used by devs as an excuse to make changes that they'd personally like to do, but which aren't necessarily improvements, e.g. rewriting from one language to another, or rewriting code they find hard to understand because there are no comments (instead of understanding the code and adding comments).

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

#276

Post by 4ntonius8lock » Thu, May 09, 2019, 4:53 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…

Though you know, sometimes organizations fall into this issue in other areas.

I once worked with a company that had that attitude toward accounting/compliance - so much more work and all because the primary holders were not in agreement, so they kicked the corporate structure can down the road.

Same goes for CS, etc.

I guess the only solution is a holistic approach, but even then sometimes someone will have to bear the brunt of being the area where people will 'will handle it', at some point a CEO will decide that is what is needed and it will be needed, even in a perfect organization.

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

#277

Post by hnlmorg » Thu, May 09, 2019, 8:50 AM UTC

Retric wrote: post #244

hnlmorg wrote: post #237

Earlier quoted context omitted.

> Accurate time estimates need to be associated with specific individuals. Someone who is familiar with the relevant code is simply faster than someone who is not. This is one of the many reasons why I disagree with giving projects to specific individuals. Not only do you end up silos of knowledge (which is a risk if that engineer should leave / get fired / die in a bus accident) but you also make it harder for yours…

I agree estimates are never going to be 100% accurate but that doesn't mean there aren't better ways to estimate than just applying guesswork based on your current teams circumstance. The entire dev team walks out, and yes this actually happens surprisingly often and could happen to you’re team tomorrow. Now, what happens to all your estimates? Well clearly anything short term is now worthless. You can build a new te…

> The entire dev team walks out, and yes this actually happens surprisingly often and could happen to you’re team tomorrow. Now, what happens to all your estimates?

The estimate is still the same because, at risk of repeating myself, you estimate on FTE and not wild guesses at a project end date. Thus you then go back to your project managers following the steps I outlined in my previous post.

Granted in the most extreme of situations you would need to factor in some upskilling time - maybe even get the team to re-groom the tickets (if you're following the agile methodology) but your method of making wild guesses wouldn't put you in any better a position should your edge case example happen. So you're not exactly winning any arguments by raising this point.

When running projects, estimations are based on the required work to do, not the team itself. Teams can fluctuate (as you keep pointing out) where as the work required should be closer to a constant. Thus any feature creeping that happens - as often does happen in software projects - gets captured and costed before so budget holders aren't surprised by hidden escalations in costs. Delivery date is then derived from totalling up the required work.

If you have a hard end date for delivery then it's up to management (eg yourself as a hiring manager, the companies board and the projects PM), to decide if you reduce the complexity of the project, do a staged release, hire more staff or even argue if the requested delivery date can be extended.

The above is how software projects should be run when they're managed properly. Other places might do things a little more adhoc but in my professional experience that almost always ends up being a worse way of managing a project, budgets and teams.

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

#278

Post by Retric » Thu, May 09, 2019, 12:05 PM UTC

hnlmorg wrote: post #277

Retric wrote: post #244

Earlier quoted context omitted.

I agree estimates are never going to be 100% accurate but that doesn't mean there aren't better ways to estimate than just applying guesswork based on your current teams circumstance. The entire dev team walks out, and yes this actually happens surprisingly often and could happen to you’re team tomorrow. Now, what happens to all your estimates? Well clearly anything short term is now worthless. You can build a new te…

> The entire dev team walks out, and yes this actually happens surprisingly often and could happen to you’re team tomorrow. Now, what happens to all your estimates? The estimate is still the same because, at risk of repeating myself, you estimate on FTE and not wild guesses at a project end date. Thus you then go back to your project managers following the steps I outlined in my previous post. Granted in the most ext…

Hiring more staff always slows progress in the short term. It has a habit of making late projects later. https://en.m.wikipedia.org/wiki/Brooks%27s_law

I understand you’re desire for an FTE to be a meaningful measure, but imperially that’s not true. As I said several times effort estimates can be used, but after deciding to add staff progress slows down for a while. So, using effort estimates you would reduce progress over the next 3 months before expecting a longer term increase in rate of accomplishment.

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

#279

Post by hnlmorg » Thu, May 09, 2019, 12:35 PM UTC

Retric wrote: post #278

hnlmorg wrote: post #277

Earlier quoted context omitted.

> The entire dev team walks out, and yes this actually happens surprisingly often and could happen to you’re team tomorrow. Now, what happens to all your estimates? The estimate is still the same because, at risk of repeating myself, you estimate on FTE and not wild guesses at a project end date. Thus you then go back to your project managers following the steps I outlined in my previous post. Granted in the most ext…

Hiring more staff always slows progress in the short term. It has a habit of making late projects later. https://en.m.wikipedia.org/wiki/Brooks%27s_law I understand you’re desire for an FTE to be a meaningful measure, but imperially that’s not true. As I said several times effort estimates can be used, but after deciding to add staff progress slows down for a while. So, using effort estimates you would reduce progres…

> Hiring more staff always slows progress in the short term. It has a habit of making late projects later.

Brooks law applies to late projects, not new ones. If you have good estimates you can determine if you need resources early on.

All a lot does depend on the size of the project. If it's something that will take 12 months or longer than extra hires definitely wouldn't have that affect. Depending on the hire and the work required, you can shorten than time frame significantly too.

However I do agree that hiring isn't a silver bullet. This is why I suggested "hiring" as one of many outcomes that can be considered rather than the preferred outcome in all situations.

> I understand you’re desire for an FTE to be a meaningful measure, but imperially that’s not true. As I said several times effort estimates can be used, but after deciding to add staff progress slows down for a while. So, using effort estimates you would reduce progress over the next 3 months before expecting a longer term increase in rate of accomplishment.

This is where another piece in the jigsaw comes into play - an employee might not be 1 FTE. They might be part time, might have leave booked, might have commitments on other teams (effectively part time from your perspective) or might be a new hire so need upskilling time. Those are just a few common examples - I'm sure you can think of others.

This is why I keep reiterating my point about calculating your figures based on work required from FTEs. By talking about new hires as you are, you're again thinking about "teams" rather than "work required". When you look at work required then you can use your team as a variable in the calculation and instantly estimations become easier.

I'm undoubtedly explaining the process poorly but I do strongly recommend you read some books or articles online about managing projects and teams using (for example) agile methodology - even if you've already worked in places that employ scrum (again, for example). You could potentially really improve how you estimate work which in turn will improve how you manage your team. From personal experience, I've been a manager for a number of years and have found my skills really improved as I've adopted those lessons too.

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

#280

Post by pureliquidhw » Thu, May 09, 2019, 1:42 PM UTC

arvinsim wrote: post #265

robbiemitchell wrote: post #257

Earlier quoted context omitted.

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.

Technical enough to understand, but probably not technical enough to build (but maybe was at some point). That's where they need to live. Their job is to align the devs and the roadmap with the business needs, prioritize what bugs to fix, and decide which enhancements are worthwhile. They also need to know when the team is bullshitting them and when a tech design is too complex or simple.

I can imagine a non-technical person could end up in this role and succeed, but someone with a technical background and some business acumen will have a much higher probability of success.