6 ms·

I'm a self-taught developer at global market leader company. I worked on the business side for years and built quite a few internal apps end-to-end completely a

I'm a self-taught developer at global market leader company. I worked on the business side for years and built quite a few internal apps end-to-end completely alone. I had no choice but to follow good practice to maintain them alone. I was quite reluctant to join the dev team, it never had a good reputation, but eventually decided to give it a go. Agile and estimations, spill overs, etc is such a pain in the ass, it feels like a pseudo-science. A lot of people spend a lot of energy on just this administration while we are way behind on many other things, like proper unit testing, good quality documentation, well established CI/CD. And everybody is focusing so much on the estimates, tickets like this was the end goal. I want to change their approach but there's a long way to go.

rvense 3y ago
I still don't understand how we went from the Manifesto's "individuals and interactions over processes and tools" to... Jira.
- hughesjj 3y ago
  To be fair I've seen some people interpret the manifesto to mean "never document anything or take time to introspect", which leads to its own set of problems. As with everything, a purposeful balance is best imo.
- Mailtemi 3y ago
  The people who were capable continued to program, while the incapable ones found an easier career path through Agile.
- senko 3y ago
  The same way people went from "everyone should be equal" to Stalin. In comparison, Jira's not so bad...
  - rvense 3y ago
    Modern day salt mines would definitely have a kanban board though
    - OkayPhysicist 3y ago
      |Current |Near Term|Future |Wish List| |Mine Salt|Mine Salt|Mine Salt|Mine Salt| |Mine Salt|Mine Salt|Mine Salt|Breaks? | |Mine Salt|Mine Salt|Mine Salt|Mine Salt| |Mine Salt| |Mine Salt|Lick Salt| |Mine Salt| | | |
- JohnFen 3y ago
  It's a result of a more fundamental problem that was present from very early on: at most companies, "doing agile" is not for the benefit of the development process or developers, but for upper management.
- Buttons840 3y ago
  -- Manifesto for Half-Arsed Agile Software Development -- We have heard about new ways of developing software by paying consultants and reading Gartner reports. Through this we have been told to value: # 1. Individuals and interactions over processes and tools and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact # 2. Working software over comprehensive documentation as long as that software is comprehensively documented # 3. Customer collaboration over contract negotiation within the boundaries of strict contracts, of course, and subject to rigorous change control # 4. Responding to change over following a plan provided a detailed plan is in place to respond to the change, and it is followed precisely That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right. -- https://www.halfarsedagilemanifesto.org/ https://www.halfarsedagilemanifesto.org/
  - fuzztester 3y ago
    Well, those consultants sound very afFORDable. "You can have any color car you like, as long as it's black." - Henry Ford
gedy 3y ago
My guess is you have a layer of "professional planners" that fiddling with dates and projections is what they do. Agreed it's mostly a waste of time.
a_c 3y ago
Modern software development is so detached from what makes software useful - getting it used. All the practices people have been preaching doesn't include the context that making sure the piece of code they written is getting used. It's like running a restaurant and all that people care is keeping the lightbulbs up.
- cheeseface 3y ago
  This type of cargo culting for sure exists, but I haven’t encountered this behavior in my career. Even all the ”agile” people I know are focused on delivering value to the end customer and the business. Meaning, they’re really interested in building software and features that people actually use.
  - a_c 3y ago
    As someone building something to tackle this problem, I'm under the impression that your situation is rare. Google famously kills product loved by customer. Reddit is committing suicide. facebook (almost) never built anything useful. I would love to learn from you how your team build software that matters if you don't mind.
    - danjac 3y ago
      Agile is a process (or a school of processes) for planning and building software to meet business goals. We can debate whether or not it's good at that, but ultimately if the business goals are misguided, or user-hostile, or both, agile isn't really to blame here.
      - lisasays 3y ago
        However if agile is used as a foil -- to project an aura of managerial competence, and keep everyone distracted while no one talks about the real problems that need to be solved -- then it also deserves blame.
    - cheeseface 3y ago
Mizoguchi 3y ago
We are all "self-taught", we learn by research, experience and by working with others. Stuff we learn at undergraduate (sometimes graduate) school is pretty much useless from a pure software engineering perspective. What we learn in school is how to do research which makes the learning part easier. As far as estimations go, unfortunately companies are no charities. There's usually a limited yearly budget that needs to be allocated to each team to build things that make the company a profit, so sometimes estimations are a necessary evil for managers to negotiate that budget and align their resources. It's not a perfect science and it is not expected to be. Also in some business domains estimations can be easy and highly accurate, so they are not necessarily pseudo science for everyone. In any case, the ability to provide estimates with lack of information is a skill that all experienced software engineering must have.
- uw7ssh8shs8 3y ago
  [flagged]
  - darkerside 3y ago
    I think you may be misinterpreting the comment. Parent is simply pointing out that most of the relevant skill in programming comes from on the job training. That's hard to disagree with.
RugnirViking 3y ago
You really do gotta keep things organised when you have a lot of Devs working on the same project. There are of course right amounts for right team size/task, but I've worked at startups growing where people started off with the individual contributor mindset and it became unmanageable as more people joined
- JohnFen 3y ago
  I don't think that anyone is arguing that there's no need for project management.
- m000 3y ago
  I think it all boils down to the (people that know what are doing)/(people who don't know what are doing or don't care) ratio. If the first group is dominant, agile is mostly about time-wasting rituals. Eventually, when the numbers of the second group swell, agile starts becoming useful.
scotty79 3y ago
> And everybody is focusing so much on the estimates, tickets like this was the end goal It is. The end goal is not to build something. It is to provide everyone sufficient excuse to get paid for a period of time.
lisasays 3y ago
Agile and estimations, spill overs, etc is such a pain in the ass, it feels like a pseudo-science. A lot of people spend a lot of energy on just this administration while we are way behind on many other things, like proper unit testing, good quality documentation, well established CI/CD. And everybody is focusing so much on the estimates, tickets like this was the end goal. Very well put. I tried being non-judgemental about agile -- first by trying to be objectively detached ("I'm not sure I can believe in this, but okay, let's see if it works.") And then by applying the serenity prayer ("I can't pretend to believe this any value any more, but hey, it's their company, whatever makes them happy.") The tipping point came for when I did the math, and realized there was a profoundly strong inverse correlation between how woo-woo management was about agile, and actual engineering competence -- or even basic communication skills and social competence (at you know, actually collaborating with others and treating them with respect; managing one's emotions instead of repeatedly creating drama over utter trivialities, etc). The low-competence, low-trust environments -- where management lied and back-stabbed every chance it could get -- loved agile. The high-competence, high-trust environments couldn't give a flying fuck about agile. So now I'm with this commenter, and their sage advice: https://news.ycombinator.com/item?id=36358127 https://news.ycombinator.com/item?id=36358127 And no, I'm not going to capitalize the word "agile", either. Or waste any more time with anyone who does.
WirelessGigabit 3y ago
Worse yet, with all those estimates and commitments we look like we only make progress when doing features that the business looks for. Other things just aren't valued.

rvense 3y ago

I still don't understand how we went from the Manifesto's "individuals and interactions over processes and tools" to... Jira.

hughesjj 3y ago
To be fair I've seen some people interpret the manifesto to mean "never document anything or take time to introspect", which leads to its own set of problems. As with everything, a purposeful balance is best imo.
Mailtemi 3y ago
The people who were capable continued to program, while the incapable ones found an easier career path through Agile.
senko 3y ago
The same way people went from "everyone should be equal" to Stalin. In comparison, Jira's not so bad...
- rvense 3y ago
  Modern day salt mines would definitely have a kanban board though
  - OkayPhysicist 3y ago
    |Current |Near Term|Future |Wish List| |Mine Salt|Mine Salt|Mine Salt|Mine Salt| |Mine Salt|Mine Salt|Mine Salt|Breaks? | |Mine Salt|Mine Salt|Mine Salt|Mine Salt| |Mine Salt| |Mine Salt|Lick Salt| |Mine Salt| | | |
JohnFen 3y ago
It's a result of a more fundamental problem that was present from very early on: at most companies, "doing agile" is not for the benefit of the development process or developers, but for upper management.
Buttons840 3y ago
-- Manifesto for Half-Arsed Agile Software Development -- We have heard about new ways of developing software by paying consultants and reading Gartner reports. Through this we have been told to value: # 1. Individuals and interactions over processes and tools and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact # 2. Working software over comprehensive documentation as long as that software is comprehensively documented # 3. Customer collaboration over contract negotiation within the boundaries of strict contracts, of course, and subject to rigorous change control # 4. Responding to change over following a plan provided a detailed plan is in place to respond to the change, and it is followed precisely That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right. -- https://www.halfarsedagilemanifesto.org/ https://www.halfarsedagilemanifesto.org/
- fuzztester 3y ago
  Well, those consultants sound very afFORDable. "You can have any color car you like, as long as it's black." - Henry Ford

gedy 3y ago

My guess is you have a layer of "professional planners" that fiddling with dates and projections is what they do. Agreed it's mostly a waste of time.

a_c 3y ago

Modern software development is so detached from what makes software useful - getting it used. All the practices people have been preaching doesn't include the context that making sure the piece of code they written is getting used. It's like running a restaurant and all that people care is keeping the lightbulbs up.

cheeseface 3y ago
This type of cargo culting for sure exists, but I haven’t encountered this behavior in my career. Even all the ”agile” people I know are focused on delivering value to the end customer and the business. Meaning, they’re really interested in building software and features that people actually use.
- a_c 3y ago
  As someone building something to tackle this problem, I'm under the impression that your situation is rare. Google famously kills product loved by customer. Reddit is committing suicide. facebook (almost) never built anything useful. I would love to learn from you how your team build software that matters if you don't mind.
  - danjac 3y ago
    Agile is a process (or a school of processes) for planning and building software to meet business goals. We can debate whether or not it's good at that, but ultimately if the business goals are misguided, or user-hostile, or both, agile isn't really to blame here.
    - lisasays 3y ago
      However if agile is used as a foil -- to project an aura of managerial competence, and keep everyone distracted while no one talks about the real problems that need to be solved -- then it also deserves blame.
  - cheeseface 3y ago

Mizoguchi 3y ago

We are all "self-taught", we learn by research, experience and by working with others. Stuff we learn at undergraduate (sometimes graduate) school is pretty much useless from a pure software engineering perspective. What we learn in school is how to do research which makes the learning part easier. As far as estimations go, unfortunately companies are no charities. There's usually a limited yearly budget that needs to be allocated to each team to build things that make the company a profit, so sometimes estimations are a necessary evil for managers to negotiate that budget and align their resources. It's not a perfect science and it is not expected to be. Also in some business domains estimations can be easy and highly accurate, so they are not necessarily pseudo science for everyone. In any case, the ability to provide estimates with lack of information is a skill that all experienced software engineering must have.

uw7ssh8shs8 3y ago
[flagged]
- darkerside 3y ago
  I think you may be misinterpreting the comment. Parent is simply pointing out that most of the relevant skill in programming comes from on the job training. That's hard to disagree with.

RugnirViking 3y ago

You really do gotta keep things organised when you have a lot of Devs working on the same project. There are of course right amounts for right team size/task, but I've worked at startups growing where people started off with the individual contributor mindset and it became unmanageable as more people joined

JohnFen 3y ago
I don't think that anyone is arguing that there's no need for project management.
m000 3y ago
I think it all boils down to the (people that know what are doing)/(people who don't know what are doing or don't care) ratio. If the first group is dominant, agile is mostly about time-wasting rituals. Eventually, when the numbers of the second group swell, agile starts becoming useful.

scotty79 3y ago

> And everybody is focusing so much on the estimates, tickets like this was the end goal It is. The end goal is not to build something. It is to provide everyone sufficient excuse to get paid for a period of time.

lisasays 3y ago

Agile and estimations, spill overs, etc is such a pain in the ass, it feels like a pseudo-science. A lot of people spend a lot of energy on just this administration while we are way behind on many other things, like proper unit testing, good quality documentation, well established CI/CD. And everybody is focusing so much on the estimates, tickets like this was the end goal. Very well put. I tried being non-judgemental about agile -- first by trying to be objectively detached ("I'm not sure I can believe in this, but okay, let's see if it works.") And then by applying the serenity prayer ("I can't pretend to believe this any value any more, but hey, it's their company, whatever makes them happy.") The tipping point came for when I did the math, and realized there was a profoundly strong inverse correlation between how woo-woo management was about agile, and actual engineering competence -- or even basic communication skills and social competence (at you know, actually collaborating with others and treating them with respect; managing one's emotions instead of repeatedly creating drama over utter trivialities, etc). The low-competence, low-trust environments -- where management lied and back-stabbed every chance it could get -- loved agile. The high-competence, high-trust environments couldn't give a flying fuck about agile. So now I'm with this commenter, and their sage advice: https://news.ycombinator.com/item?id=36358127 https://news.ycombinator.com/item?id=36358127 And no, I'm not going to capitalize the word "agile", either. Or waste any more time with anyone who does.

WirelessGigabit 3y ago

Worse yet, with all those estimates and commitments we look like we only make progress when doing features that the business looks for. Other things just aren't valued.