4 ms·

We have no architects. Everything is design-by-committee, and the design is horrible. It wouldn't matter if we had them. The business believes iterating on t

by snarfy 12y ago

We have no architects. Everything is design-by-committee, and the design is horrible. It wouldn't matter if we had them. The business believes iterating on the business plan and direction is agile development, the result being a code base full of dead ends and code that should be refactored or deleted, but can't because it will take a non-trivial effort to do so since data is already deployed to production. If we ever do take the time to clean up, that's a sprint the business doesn't get any backlog items, so those sprints are few and far between.

keithnoizu 12y ago
Someone probably should have architected out that release pipeline and planned for scheme version control and a more efficient data migration process. ;)
antris 12y ago
Doesn't sound like agile development to me. In Agile development you usually refactor as you go. Refactoring is not a separate task, it's part of the process. http://www.extremeprogramming.org/rules/refactor.html http://www.extremeprogramming.org/rules/refactor.html http://c2.com/cgi/wiki?WhatIsRefactoring http://c2.com/cgi/wiki?WhatIsRefactoring
ExpiredLink 12y ago
> The business believes iterating on the business plan and direction is agile development The perils of Agile. You are only allowed to do what you stakeholders understand. The rest is ignored.
- antris 12y ago
  > The perils of Agile. You are only allowed to do what you stakeholders understand. The rest is ignored. Sounds like quite a passive aggressive way to solve a communication problem. "You only said we needed feature X, you didn't tell us not to mess up our codebase during the process". It's not the stakeholders responsibility to tell you how to do your job. You don't wear clothes at work because it's in the backlog, you do it because it would be unprofessional not to. Even when stakeholders have asked me to take shortcuts, they usually seem very level-headed about it once you start the dialog. I've talked to stakeholders proactively about tradeoffs of taking shortcuts and they seem to understand when I compare "not refactoring" with "making a mess". In my experience, people understand what messes are. If we make a mess, it will slow us down as long as it is there. We can clean it up later, too, but it will cost us more because it is slowing us for a longer time. Taking shortcuts without telling stakeholders is unprofessional. If the stakeholders don't explicitly tell you to not refactor, refactoring is implied.
  - Touche 12y ago
    My experience is different. "We need feature X" almost always comes with an implicit or explicit "as fast as humanly possible".
    - antris 12y ago
      Of course they want it as fast as possible. But they also want the code to not slow the team down later on. And they want a cure for cancer, eternal happiness and world peace too. My point is that people say and want all kinds of things, but when you engage in dialog about tradeoffs, they usually understand what refactoring is and how it affects long-term development speed.
  - ExpiredLink 12y ago
    What do you expect from a method that is based on visible results for short term iterations (a.k.a. sprints)?
    - bgilroy26 12y ago
      Hardly anything in software is literally visible. Wouldn't visibility be an analogy for clear and tangible? With enough communication any result can be a visible one because everybody understands why it is important.
daxfohl 12y ago
Sounds like an "eternally vaporware startup" to me. I've worked for one of those before. The work can be interesting at times as you feel the need to do something nobody else has done before. But then it never gets anywhere because the whole premise is based on things that are fundamentally unsound/impossible. My experience is then you get your pay cut by the CEO because you're not producing anything "of value", and then you get sued by the investors for the same reason (okay I've got my name on provisional patents that aren't based on reality, but I refuse to give them up after I quit, probably mostly out of spite). Still, I say get out while (if) you still can, and move on to better things.

by snarfy 12y ago

keithnoizu 12y ago

Someone probably should have architected out that release pipeline and planned for scheme version control and a more efficient data migration process. ;)

antris 12y ago

Doesn't sound like agile development to me. In Agile development you usually refactor as you go. Refactoring is not a separate task, it's part of the process. http://www.extremeprogramming.org/rules/refactor.html http://www.extremeprogramming.org/rules/refactor.html http://c2.com/cgi/wiki?WhatIsRefactoring http://c2.com/cgi/wiki?WhatIsRefactoring

ExpiredLink 12y ago

> The business believes iterating on the business plan and direction is agile development The perils of Agile. You are only allowed to do what you stakeholders understand. The rest is ignored.

antris 12y ago
> The perils of Agile. You are only allowed to do what you stakeholders understand. The rest is ignored. Sounds like quite a passive aggressive way to solve a communication problem. "You only said we needed feature X, you didn't tell us not to mess up our codebase during the process". It's not the stakeholders responsibility to tell you how to do your job. You don't wear clothes at work because it's in the backlog, you do it because it would be unprofessional not to. Even when stakeholders have asked me to take shortcuts, they usually seem very level-headed about it once you start the dialog. I've talked to stakeholders proactively about tradeoffs of taking shortcuts and they seem to understand when I compare "not refactoring" with "making a mess". In my experience, people understand what messes are. If we make a mess, it will slow us down as long as it is there. We can clean it up later, too, but it will cost us more because it is slowing us for a longer time. Taking shortcuts without telling stakeholders is unprofessional. If the stakeholders don't explicitly tell you to not refactor, refactoring is implied.
- Touche 12y ago
  My experience is different. "We need feature X" almost always comes with an implicit or explicit "as fast as humanly possible".
  - antris 12y ago
    Of course they want it as fast as possible. But they also want the code to not slow the team down later on. And they want a cure for cancer, eternal happiness and world peace too. My point is that people say and want all kinds of things, but when you engage in dialog about tradeoffs, they usually understand what refactoring is and how it affects long-term development speed.
- ExpiredLink 12y ago
  What do you expect from a method that is based on visible results for short term iterations (a.k.a. sprints)?
  - bgilroy26 12y ago
    Hardly anything in software is literally visible. Wouldn't visibility be an analogy for clear and tangible? With enough communication any result can be a visible one because everybody understands why it is important.

daxfohl 12y ago

Sounds like an "eternally vaporware startup" to me. I've worked for one of those before. The work can be interesting at times as you feel the need to do something nobody else has done before. But then it never gets anywhere because the whole premise is based on things that are fundamentally unsound/impossible. My experience is then you get your pay cut by the CEO because you're not producing anything "of value", and then you get sued by the investors for the same reason (okay I've got my name on provisional patents that aren't based on reality, but I refuse to give them up after I quit, probably mostly out of spite). Still, I say get out while (if) you still can, and move on to better things.