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

Little Tasks, Little Trust

adamard.com

Post reply on HN
Print view View original

41–50 of 93 posts

Re: Little Tasks, Little Trust

#41

Post by treis »

jrumbut wrote: post #28
treis wrote: post #17

Earlier quoted context omitted.

The bigger problem is that if you delegate A and B to Vincent as the article suggests is that often it becomes King Vincent lord and ruler of A and B. They are the only one allowed to touch A and B, and worse may be the only one's capable of touching A and B. You can end up with a bunch of these little fiefdoms and getting anything done quickly becomes an issue of appeasing a few petty despots. That's a little bit ex…

If you don't create the King Vincent, you become the King Vincent.

Not really. Even if you have one person architecting the system you will have at least a couple developers implementing. Knowledge will be spread across multiple people preventing any one of them being indespensible.

Re: Little Tasks, Little Trust

#42

Post by PaulHoule »

All of those tools have a mismatch between how different people involve see their work.

At one end there is the "user story" which can be great for envisioning but a poor match for describing the work that has to get done. There is also the "bug" found by the end user or by the tester or the code, not to mind the "feature request".

People see those as different but when quality counts the coder is going to do the same thing no matter what a change request is called. A change request can also be scoped to subsystems, such as a web front end vs a back end. There are many reasons to keep separate paperwork for those systems (maybe different people do the work!) but when the tester fails it, the tester has no idea if it is a front end problem or a back end problem so it is 50-50% they will fail the right ticket, etc.

Re: Little Tasks, Little Trust

#43

Post by 908B64B197 »

mattwad wrote: post #33
zerof1l wrote: post #30

I am lucky to work with a reasonable company that prioritizes people over methodology. We follow Scrumban - something between Scrum and Kanban. We have sprints, tickets, story points, daily standups, but it is humane. Before sprint starts, tickets are estimated and assigned to developers. Each developer gets more-less the same amount of story points. Since the codebase is very big, if possible, a developer would get…

> Every third sprint is a tech sprint. Can you elaborate on this? I love the sound. I get pushback even suggesting a tech sprint once every 6 weeks. What kinds of projects fall under here, and do you still work on product? What's the product team work during this sprint? Thanks!

> I get pushback even suggesting a tech sprint once every 6 weeks.

Either get a dedicated team for this or a better manager.

Re: Little Tasks, Little Trust

#44

Post by notriddle »

As much as I understand the frustration here, the reason why programmers aren't trusted to make decisions is because they've consistently failed to earn that trust.

Big tasks with lots of room for error is what gave us the platforms of the 80's: barely-usable "power" platforms like Linux, over-promise-under-deliver demo OS's like Windows 95, the pile of hacks called The Web, and the pile of less-famous code that gives rise to organizations with names like Destroy All Software.

The micromanagement might not be much better, but acting like coders should be given more trust and responsibility is laughable.

Re: Little Tasks, Little Trust

#45

Post by thrower123 »

PaulHoule wrote: post #31

I am a front-line coder but if I don't restrain myself I will usually be the #1 person for creating tickets in the ticket system because I like to split tasks into great detail enough to drive my co-workers nuts. There was a time I did updates to a web form application and I could break the work down to tasks in 10 minute increments and plan it would take six hours and I would really get it done in 5.8 hours. The des…

How long did it take you to create all the tickets to break the work down into 10 minute subtasks?

Whatever ticketing system you're using must be fast as hell if you're able to do that and not spend more time doing data entry than actually doing the work...

Re: Little Tasks, Little Trust

#47

Post by rektide »

very glad to have someone put this down on paper.

i sometimes put little rants onto social media about how micromanaged work is, & especially how jealously developers time is guarded- work on the ticket, one ticket, nothing else! this is a much better reasoned foothold.

i have felt very alone for feeling the wrongness of this completely accepted seemingly 100% universally deployed new "agile" process. i miss the old days, of having big tasks, and freedom to work widely on them, figure out where the good opportunities lie. hearing someone else, anyone else, speak out that they think other ways may have value, it's relieving to hear. just a little bit de-alienating.

Re: Little Tasks, Little Trust

#48

Post by RcouF1uZ4gsC »

notriddle wrote: post #44

As much as I understand the frustration here, the reason why programmers aren't trusted to make decisions is because they've consistently failed to earn that trust. Big tasks with lots of room for error is what gave us the platforms of the 80's: barely-usable "power" platforms like Linux, over-promise-under-deliver demo OS's like Windows 95, the pile of hacks called The Web, and the pile of less-famous code that give…

> over-promise-under-deliver demo OS's like Windows 95,

Windows 95 was a very successful OS given all the trade offs it had to achieve:

1. Long file names without breaking backwards compatibility

2. Be able to run 32-bit software while also being able to run DOS programs that thought they were the only thing running on the computer

3. Have all the existing Windows software just run without any issues, even when they used undocumented functions or did stuff that was bad.

4. Do all this with 4 MB of RAM and a 33 MHz 386.

Re: Little Tasks, Little Trust

#49

Post by rthomas6 »

notriddle wrote: post #44

As much as I understand the frustration here, the reason why programmers aren't trusted to make decisions is because they've consistently failed to earn that trust. Big tasks with lots of room for error is what gave us the platforms of the 80's: barely-usable "power" platforms like Linux, over-promise-under-deliver demo OS's like Windows 95, the pile of hacks called The Web, and the pile of less-famous code that give…

I can't tell if this is satirical or not.

The examples of bad software given are two of the most popular and widely used OS's of all time, and the internet. Are these things piles of hacks? Yes, but for Linux and the internet, they are arguably antifragile, and are so because of the way they're made. They have stood the test of time in a way that no top-down managed product has done that I'm aware of. The world would be so lucky to get another Linux-like project and another internet-like project.

Re: Little Tasks, Little Trust

#50

Post by itsmemattchung »

zerof1l wrote: post #30

I am lucky to work with a reasonable company that prioritizes people over methodology. We follow Scrumban - something between Scrum and Kanban. We have sprints, tickets, story points, daily standups, but it is humane. Before sprint starts, tickets are estimated and assigned to developers. Each developer gets more-less the same amount of story points. Since the codebase is very big, if possible, a developer would get…

> The goal is to improve the system.

This. I do believe that the act of breaking down tasks helps clarify assumptions and helps paint a more accurate picture of what needs to be accomplished for a particular task. Can breaking down the task into small bite-size chunks be a little demoralizing? Maybe. But I don't necessarily view it that way, assuming that the person owning the task is part of the initial conversation.

In short, the breaking up of tasks should be a conversation, not some top down mandate.

Post reply on HN