4 ms·

Developers don't like: * Committing to dates and then being accountable for the results * Spending time planning, rather than "doing" * Admitting to business

Developers don't like: * Committing to dates and then being accountable for the results * Spending time planning, rather than "doing" * Admitting to business leaders that much of their work time is not spent writing lines of code, but dallying in all the interesting byways of the field, favorite websites, pet projects, and random semi-related technology interests * Sitting in meetings of any sort (sprint planner and retrospective) * Having spoken, out-loud disagreements and negotiations in order to arrive at a consensus (sprint point estimations) * Having their mistakes, miscalculations, lack of planning visible to everyone on a big monitor (sprint board / retro) * Getting out of their chairs to go talk to someone else in order to remove a blocker or understand a dependency (task estimation and completion by end-of-sprint) * Anyone involved in the process that isn't a coder (Scrum Master, Project Manager)

supercanuck 7y ago
In my experience, nobody likes these things. Carpenters don't like: * Committing to dates and then being accountable for the results * Spending time planning, rather than "doing" * Admitting to business leaders that much of their work time is not spent chiselling wood, but dallying in all the interesting byways of the ... * Sitting in meetings of any sort * Having spoken, out-loud disagreements and negotiations in order to arrive at a consensus * Having their mistakes, miscalculations, lack of planning visible to everyone on a big monitor * Getting out of their chairs to go talk to someone else in order to remove a blocker or understand a dependency (task estimation and completion by end-of-sprint) * Anyone involved in the process that isn't a tradesman
cloverich 7y ago
Developers dislike: - Loosely estimating dates, then having management set them in stone - Spending more time talking about things than it would take to do them ("planning") - convincing business leaders that engineering is more than just writing code - sitting in meetings that add little value to the team - arguing over made up numbers for vague deliverables - having their mistakes, miscalculations, and other normal aspects of software development enumerated and held against them, as though it was an actual problem - having "scrum masters" come up with straw men to justify even more process - reporting to too many non-technical managers The last point sums most of it up though. In many orgs, Agile is used as an attempt to compensate for lack of technical leadership, as though process can obviate the need. You need some, most, or all of your management and executive team to have technical foundations, depending on how technical your product is. You wouldn't put a football coach in charge of a coal mining operation (forgive the hyperbole). The same principle applies to software.
jffhn 7y ago
>Committing to dates and then being accountable for the results Being forced to commit to dates, as only a soothsayer would dare. >Spending time planning, rather than "doing" Because "doing", as you say, helps planning. Development is not production (which is compilation), it's conception all the way, it's the non-automatable and hard to estimate phase of creating order out of void and chaos, by completing up to a complexity that no one can hold at once in his mind, and precising unambiguously into a formal language, some vague expectations expressed in a natural language, or some creation imagined by the developer himself. Preventing a developer from "doing" is like preventing a mathematician from interacting with his board. Manufacturing: repetitive, predictable. Mindfacturing: non-repetitive, unpredictable. Related quotes: "Programming is a good medium for expressing poorly understood and sloppily-formulated ideas." (Marvin Minsky) "The computer revolution is a revolution in the way we think and the way we express what we think." "My real goal is to transform things that are hard to understand into things that are easy to understand, and programming has been one of the tools in doing that." "I always learn things by writing programs." "Clarity sometimes need programming because (...) if I write a program that doesn't represent something sensible, I get an error." (G. J. Sussman, https://www.infoq.com/presentations/Expression-of-Ideas https://www.infoq.com/presentations/Expression-of-Ideas) "What I cannot create, I do not understand." (R. Feynmann) "A number of people are desperately waiting for the software industry to reach some kind of maturity and start resembling traditional industries. They will have to wait forever." (V. Lextrait, Mindfacturing)
Rainymood 7y ago
>Committing to dates and then being accountable for the results I found a very good way of getting around this. If you need to estimate a task, estimate it honestly in your head (say 2-3 days) and then double the amount. It almost feels like cheating but with this method I have consistently delivered timely on my responsibilities. This method works because we usually plan way too optimistically.

supercanuck 7y ago

In my experience, nobody likes these things. Carpenters don't like: * Committing to dates and then being accountable for the results * Spending time planning, rather than "doing" * Admitting to business leaders that much of their work time is not spent chiselling wood, but dallying in all the interesting byways of the ... * Sitting in meetings of any sort * Having spoken, out-loud disagreements and negotiations in order to arrive at a consensus * Having their mistakes, miscalculations, lack of planning visible to everyone on a big monitor * Getting out of their chairs to go talk to someone else in order to remove a blocker or understand a dependency (task estimation and completion by end-of-sprint) * Anyone involved in the process that isn't a tradesman

cloverich 7y ago

Developers dislike: - Loosely estimating dates, then having management set them in stone - Spending more time talking about things than it would take to do them ("planning") - convincing business leaders that engineering is more than just writing code - sitting in meetings that add little value to the team - arguing over made up numbers for vague deliverables - having their mistakes, miscalculations, and other normal aspects of software development enumerated and held against them, as though it was an actual problem - having "scrum masters" come up with straw men to justify even more process - reporting to too many non-technical managers The last point sums most of it up though. In many orgs, Agile is used as an attempt to compensate for lack of technical leadership, as though process can obviate the need. You need some, most, or all of your management and executive team to have technical foundations, depending on how technical your product is. You wouldn't put a football coach in charge of a coal mining operation (forgive the hyperbole). The same principle applies to software.

jffhn 7y ago

>Committing to dates and then being accountable for the results Being forced to commit to dates, as only a soothsayer would dare. >Spending time planning, rather than "doing" Because "doing", as you say, helps planning. Development is not production (which is compilation), it's conception all the way, it's the non-automatable and hard to estimate phase of creating order out of void and chaos, by completing up to a complexity that no one can hold at once in his mind, and precising unambiguously into a formal language, some vague expectations expressed in a natural language, or some creation imagined by the developer himself. Preventing a developer from "doing" is like preventing a mathematician from interacting with his board. Manufacturing: repetitive, predictable. Mindfacturing: non-repetitive, unpredictable. Related quotes: "Programming is a good medium for expressing poorly understood and sloppily-formulated ideas." (Marvin Minsky) "The computer revolution is a revolution in the way we think and the way we express what we think." "My real goal is to transform things that are hard to understand into things that are easy to understand, and programming has been one of the tools in doing that." "I always learn things by writing programs." "Clarity sometimes need programming because (...) if I write a program that doesn't represent something sensible, I get an error." (G. J. Sussman, https://www.infoq.com/presentations/Expression-of-Ideas https://www.infoq.com/presentations/Expression-of-Ideas) "What I cannot create, I do not understand." (R. Feynmann) "A number of people are desperately waiting for the software industry to reach some kind of maturity and start resembling traditional industries. They will have to wait forever." (V. Lextrait, Mindfacturing)

Rainymood 7y ago

>Committing to dates and then being accountable for the results I found a very good way of getting around this. If you need to estimate a task, estimate it honestly in your head (say 2-3 days) and then double the amount. It almost feels like cheating but with this method I have consistently delivered timely on my responsibilities. This method works because we usually plan way too optimistically.