I remember removing a single line taking me about a whole day. Was working on an embedded c++ project (a tv) and for some reason it was randomly stucking in an infinite loop. Debugging tools were minimal and it took me a while to figure out it was stucking in some kind of mutex and all I did was removing one mutex lock because it wasn't necessary.
You've only added two lines – why did that take two days?
261–270 of 522 posts
Re: You've only added two lines – why did that take two days?
#262A 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…
It's all correct: 90% takes 5 days and the rest 10% will take 3 months.
Except the UI guys chewed through 2 months in elapsed time getting the design approved and across the line and you now have to compress the 3 months you told them you would need into one to meet the delivery date management had in mind.
Re: You've only added two lines – why did that take two days?
#263Earlier quoted context omitted.
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.
It's an anti-pattern to simply not demo any progress until done. If you're doing agile right (loaded statement), the solution is to make sure everyone understands what's being done. If the audience is expecting all demos to show complete products, find a different audience to demo done-but-incomplete work. The idea is to get feedback before you've sunk six months into something that may not meet expectations.
I totally agree. Having weekly demos where we showcase unfinished features has been, in my experience, one of the main avenues where we have learned of issues / conflicts / problems with those features at exactly the right time where we could still fix them.
Not having demos of incomplete features would just hide the issues until they are released to the final customers, creating a problem you didn't have before, and making it much more complex to solve.
Re: You've only added two lines – why did that take two days?
#264Do 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.
> Do people actually have fights like this with management at their companies? There was a time when I thought this video was funny: https://www.youtube.com/watch?v=BKorP55Aqvg
I used to think that was hilarious.
These days I can only look at it and think "the expert is terrible at calm confrontation and good communication. There would be no problem if he had developed those skills."
Re: You've only added two lines – why did that take two days?
#265Earlier 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…
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…
I've been with a few companies that waterfall in two-week cadences and call it Agile...
They usually expect a fully working demo
Re: You've only added two lines – why did that take two days?
#266Earlier 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…
Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though…
> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done.
I take a different but similar approach when I run into situations where I want to get something small in front of a business user before it’s completely ready: I make sure it’s visibly broken in a way that doesn’t detract from my goal for the meeting.
For example: I have a registration form that I want to talk through. The state drop down will only have 3 entries, one validation error will always display, and on final submit you get a “failed” alert instead of a dummy page.
It lets me walk through the page and get whatever feedback I need, but it feels completely broken so non-technical users expect it to take more time to conplete.
Re: You've only added two lines – why did that take two days?
#267A 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…
If you have a non-technical manager, quit your job immediately.
Re: You've only added two lines – why did that take two days?
#268Do 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.
So far I've worked in one place which didn't use version control in 2007, one place which had reluctantly started using version control just before I started in 2010, several places where automated tests were considered pure waste, where everybody had full access to production, where backups were untested, where one or two people held crucial knowledge which was not shared with anybody else, etc. The real world moves a hell of a lot slower than best practice.
Re: You've only added two lines – why did that take two days?
#269This 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 combinat…
People who don't know how to write software have to use "boss" heuristics when determining who is a superstar. Qualities that take prominence over quickly writing high-quality software:
1. "Can do" attitude 2. Never backs down from a challenge 3. Being the glue that holds the company together 4. ...
As you can see these are all the kind of things you can't put your finger on but you "know it when you see it". When they see it, it nearly always looks like their reflection.
Re: You've only added two lines – why did that take two days?
#270A 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…
> just because you can see something, that doesn't mean it's secure
I have yet to see secure software... does that even exist?