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

101–110 of 522 posts

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

#101

Post by msclrhd »

zabzonk wrote: post #50

Nobody should manage programmers who is not themselves a very experienced programmer. Otherwise, you are in Dilbert Country.

The tricky part of this is that not all programmers make good managers, or want to be promoted into management. They are different skill sets. That said, having a basic understanding of the difficulties and things that take time (learning new technology, investigating/debugging an issue, etc.) would be a good thing to have as a manager. Also, being able to assist where possible -- asking if the developer needs someone to help out, finding people with the relevant skills to mentor the developer (or finding suitable courses/training/books), etc.

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

#103

Post by caymanjim »

ftio wrote: post #89
caymanjim wrote: post #31

A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…

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…

In a company that understands and embraces agile software practices, this works well. You demo small things that are done, and prototypes are understood as just mockups designed to drive future work. Alas not everyone in power gets it. In more egregious cases, I've been in adversarial environments where teams were pitted against each other to appear "more done." Obviously a recipe for failure. I'm fortunate enough to be able to be more selective in where I work now, and have the experience to drive the choice.

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

#104

Post by Jtsummers »

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 ?

Program logic error:

  // return the maximum value from an array
  return array.min();
Specification error:

  Only users with role X can access this content.
  [where X should've been Y]
In the former case, a test should catch it (because the code isn't doing what we believe, per spec, it should be doing). In the latter case, only validation (confirming with customers) can catch it. Any test that is run against the code will be based on the spec which tells us to do the wrong thing.

Though we usually didn't run into the latter case, ours were mostly embedded systems. So the problem was more like: You implemented this against Industry Standard 1234-A, but we're implementing against Industry Standard 1234-B which says that message Foo word 15 now has a range of 1-20, not 1-19, and 20 means "cease operations", and 18 has been changed from "cease operations" to "halt and catch fire".

So one system was developed per one spec, and another per a slightly different spec. The other common scenario was that the specs weren't created from thin air, but rather based on a preexisting system. And the authors of the spec misinterpreted what the preexisting system did and gave an incorrect specification for a behavior. When testing against the old system (or with the old system as these were mostly communication systems) you'd see a difference in behavior or failure to communicate. But since tests were never truly comprehensive, many of these errors could make it out into the world.

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

#105

Post by csours »

ftio wrote: post #89
caymanjim wrote: post #31

A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…

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…

I'm still conflicted about this. On the one hand I agree. On the other, I wish we could educate people enough for them to understand Proof of Concepts and Minimum Viable Products.

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

#106

Post by VLM »

kevsim wrote: post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

At most of the big companies I worked at (over 500 employees) there is a steering committee doing prioritization work and continuous integration test suites and an elaborate change control committee and process such that fixing a spelling error will take much more than two days.

Whats nice about the proceduralism is you can document that the steering committee only meets once a week on Tuesday afternoons and change control meets on Thursday. And everyone knows the automated test suite on DEV takes about half a working day. So if a change can't be worked into the schedule in less than a day, it'll never pass CI testing before the change control meeting so it'll take more than a week.

Whats bad, is mgmt would like you to complete multiple changes perhaps at the same time which always complicates the change control process especially if change #7 failed last week so company policy is to roll everything back and now we have 13 changes, two weeks worth, to complete next weekend. Also whats bad, is knowing its a corporate nightmare to make any change, why did I make a mistake to begin with of having the buttons swapped or a misssspelling or whatever.

I find the big metric now a days is backlog. Lets see the number of request tickets decrease this week instead of increase. That leads to intense pressure to roll multiple problems into one ticket.

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

#107

Post by BareNakedCoder »

caymanjim wrote: post #31

A variant of this that has driven me to quit more than one job is having a non-technical manager look at a UI prototype and consider that 90% of the solution. "The UI guys had this page ready two months ago! Why doesn't this work yet?" It's even worse when you present a working prototype. They simply don't understand that the backend functionality is what's doing the bulk of the work, and just because you can see som…

Has happened to me too more than once. I usually reply that the UI prototype is like a Hollywood movie set: what looks like a real building is fake, just a single wall. The real building still needs to be built. That explanation sometimes works, often doesn't :(

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

#108

Post by vikramkr »

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.

That's a pretty bad breakdown in communication- the manager should have communicated how the contractor was paid and the programmer should have spent their time working in line with that - whichever end that breakdown happened on that sounds like that led to an awful lot of misery and wasted time - ouch

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

#110

Post by akhilcacharya »

birdyrooster wrote: post #16
kevsim wrote: post #5

Do people actually have fights like this with management at their companies? Not trying to knock the author, but I'm just surprised anyone would actually hear this kind of comment in 2020. I'd think by now any and all metrics tying lines of code to productivity would be long dead.

I know someone that worked at some skeezy company in Menlo Park that got passed up for a raise after spending months navigating the bureaucracy to save the company millions on their operating costs because they didn't write enough code. This was in the last four years. Edit: And they quit right afterwards.

The defense I've seen is that it works reasonably well as a measure of productivity _if_ you're working in a similar team and in a stable codebase.

From what I understand a lot of product teams at FB have nearly frictionless development tooling for their use cases so the pressure is to produce volume.

Post reply on HN