Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You've only added two lines – why did that take two days?

mrlacey.com

Post reply on HN
Print view View original

121–130 of 522 posts

Re: You've only added two lines – why did that take two days?

#121

Post by ftio »

core-questions wrote: post #115
ftio wrote: post #89

Earlier quoted context omitted.

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…

> incentivizes teams to build things in small, shippable components. Isn't this a bit of a fallacy? Not everything can be broken down into chunks of work that fit into a single sprint. There's a reason I stopped bothering with Scrum a while ago, and this is high on the list.

This doesn't require that things fit into a single sprint. It just incentivizes teams to ship their work in smaller chunks.

If it helps motivate a team to divide some four-sprint piece of functionality into two shippable chunks that each take two sprints, I'd call that a win. Customers get something a bit faster even if it's not single sprint-sized.

Re: You've only added two lines – why did that take two days?

#122

Post by qayxc »

touristtam wrote: post #71
WalterBright wrote: post #32

Earlier quoted context omitted.

Many people assume their manager knows what the employee is doing. They often aren't, meaning they go by what they can see, which is lines of code. The smart thing to do is to regularly keep your manager updated on what you're doing, especially if they don't come by regularly and ask you. Especially if you are WFH.

Task completion should be the metric, not line counts, otherwise the incentive is creating the most bloated piece of software and the most comprehensive unit-test possible. Any system is going to be (ab)used by the employee to their benefit.

Relevant post: https://news.ycombinator.com/item?id=23762526

Task completion would also be abused, because it's too vague. It simply shifts the burden to the one formulating the task (e.g. preventing holes in the specification like missing performance or hardware requirements).

Exaggerated example: if the "task" is to automatically deliver a report containing certain data and formatted in a specified way, the easy way might be an implementation that stalls the DB server for hours with deeply nested FULL OUTER JOINs on non-index fields.

The task would be completed quickly and arguably correctly, since neither runtime nor memory requirements were explicitly specified...

But you said it yourself, any system is going to be abused...

Re: You've only added two lines – why did that take two days?

#124

Post by beckingz »

neatze wrote: post #76
Jtsummers wrote: post #13

Earlier quoted context omitted.

My first boss and my boss two positions ago both thought that way. It was incredibly frustrating. Along with: If only you programmers would stop putting in bugs we'd ship perfect software every time. (When most of the "bugs" were specification errors and not program logic errors.)

Where does program specification ends and where does program logic starts ?

Where management says it does.

Re: You've only added two lines – why did that take two days?

#125

Post by pintxo »

not2b wrote: post #59

I recall a story about someone at a government contractor who did a major refactoring and removed thousands of lines of code from a project, increasing its performance, only to be told by management that they'd signed a contract that said the company got paid by lines of code delivered, and his improvement would cost them tens of thousands of dollars, so revert the whole thing.

As long as we are counting LOC before compiling, that can be solved easily:

    if (false) {
      /* original code stays here, as we are payed by LOC */
    } else {
      /* write your new code here */
    }

Re: You've only added two lines – why did that take two days?

#127

Post by MattGaiser »

core-questions wrote: post #115
ftio wrote: post #89

Earlier quoted context omitted.

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…

> incentivizes teams to build things in small, shippable components. Isn't this a bit of a fallacy? Not everything can be broken down into chunks of work that fit into a single sprint. There's a reason I stopped bothering with Scrum a while ago, and this is high on the list.

There is a reason that teams with mostly non-technical leadership deliver broken software as your choices are feature driven architecture with absurd glue or being asked "why isn't it done yet"?

Re: You've only added two lines – why did that take two days?

#128

Post by mirekrusin »

This is achilles heel of non-tech managers. You can link as many articles like that as you want, it will still be a problem. They may be more aware of it, but it will still be, daily struggle. Non-tech manager should be paired with tech-lead with high trust relationship for this not to be a problem.

This example is just one case/symptom of much larger problem.

Non-tech managers will only see fast progress on combination of: - poor developer - doing fast progress - with shitty code - on good quality codebase

They will see tech lead/good coder as asshole in general, with poor performance in general, who for some unknown reason is respected for their code and sometimes magically ticks off hard problems quickly which "must be a coincidence, overestimated work to begin with or something like that" on combination of: - person who actually cares about the project - who repairs shitty code/tech debt - who thinks more deeply about the problem - and as a bigger picture issue, not just ticking off ticket with the lowest resistance possible - writes good quality code - if the problem breaks current abstrations, refactors abstration itself - who cares about readers of the code

Re: You've only added two lines – why did that take two days?

#130

Post by ddingus »

core-questions wrote: post #115
ftio wrote: post #89

Earlier quoted context omitted.

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…

> incentivizes teams to build things in small, shippable components. Isn't this a bit of a fallacy? Not everything can be broken down into chunks of work that fit into a single sprint. There's a reason I stopped bothering with Scrum a while ago, and this is high on the list.

Why would it be?

For all the things that can be atomic like that, it's good practice.

The bigger ones just take time, and aren't shown, until ready for use.

Post reply on HN