3 ms·

So you're saying he's responsible for 90% of what I hate about software jobs these days (TDD as dogma, Agile, forced pair programming).

nostrademons 10y ago
Probably, yes. I think people forget everything they hated before TDD, Agile, XP, etc. Namely the endless parade of bugs, management making unrealistic promises, perpetual crunch time, death marches with no end in sight, code fiefdoms where touching any other engineers' code was basically impossible. Software is hard. It is getting marginally easier with time, but it still is a lot harder than most peoples' expectations of what it should be. Hence most developers end up disillusioned, frustrated, and unhappy, but this is a product of our expectations more than our processes. A job isn't supposed to make you happy, it's supposed to make your customers happy.
tigershark 10y ago
He is responsible for the software engineering evolution from a model that was good for building static stuff like houses and bridges to a model that works well with dynamic stuff with continuously evolving requirements. Why do you hate TDD, agile and pair programming and what software designing methodology are you following?
- superswordfish 10y ago
  At the risk of outing myself, it's a strange correspondence based approach. The idea is that we never commit to a repository but instead email changes to each other, making a patch queue. This has the benefit of forcing every commit to be code reviewed. The process is that we get an email to start work on some new ticket, which will be a reply from the "tip" email that we are supposed to base our work on, with a new subject. This is a development branch, so to speak. We have separate email addresses for separate projects, so project management is fairly hands-off. Requirements are hashed out in these email chains. This has the benefit of making all of our code "literate" in that it is adjacent the requirements.

nostrademons 10y ago

Probably, yes. I think people forget everything they hated before TDD, Agile, XP, etc. Namely the endless parade of bugs, management making unrealistic promises, perpetual crunch time, death marches with no end in sight, code fiefdoms where touching any other engineers' code was basically impossible. Software is hard. It is getting marginally easier with time, but it still is a lot harder than most peoples' expectations of what it should be. Hence most developers end up disillusioned, frustrated, and unhappy, but this is a product of our expectations more than our processes. A job isn't supposed to make you happy, it's supposed to make your customers happy.

tigershark 10y ago

He is responsible for the software engineering evolution from a model that was good for building static stuff like houses and bridges to a model that works well with dynamic stuff with continuously evolving requirements. Why do you hate TDD, agile and pair programming and what software designing methodology are you following?

superswordfish 10y ago
At the risk of outing myself, it's a strange correspondence based approach. The idea is that we never commit to a repository but instead email changes to each other, making a patch queue. This has the benefit of forcing every commit to be code reviewed. The process is that we get an email to start work on some new ticket, which will be a reply from the "tip" email that we are supposed to base our work on, with a new subject. This is a development branch, so to speak. We have separate email addresses for separate projects, so project management is fairly hands-off. Requirements are hashed out in these email chains. This has the benefit of making all of our code "literate" in that it is adjacent the requirements.