4 ms·

I mentioned this idea to a very knowledgeable enterprise architect. I was mentioning how much I'd enjoyed being able to use the code review process in this way.

I mentioned this idea to a very knowledgeable enterprise architect. I was mentioning how much I'd enjoyed being able to use the code review process in this way. His reply: As good of an idea that is, it breaks Agile. So long as the code meets the biz-provided spec, it must be accepted, and if there are other concerns with the code, to make a tech debt ticket to address it at a later date. This, of course, horrified me.

haggy102 5y ago
Anyone with Architect in their title receives skepticism from me. I've turned down title changes that include it and I refuse to put it on my LinkedIn.
- akvadrako 5y ago
  Even people designing buildings?
- vinceguidry 5y ago
  His world seemed completely and utterly divorced from mine. He was deeply connected with big enterprises and how they manage to meet business objectives regardless of not being software engineers themselves. In our world, we take for granted that our managers and leadership are technically proficient. In his, the "Engineering Manager" is a rarity, the people managing engineers are just ordinary managers. Software architecture, in this world, is how you escape the rat race of soulless ticket punching without having to go into management. You use your skills and experience in an advisory role. Obviously there are better or worse architects, I've had the pleasure of working with really good ones. But it often feels like a title and field borne out of a need to retain top talent. (read, not push them away to competitors)
- dangus 5y ago
  I think that attitude is a little short-sighted, and perhaps a little bit of "anyone that isn't a pure developer is incompetent" elitism. For one thing, titles are just titles, and they stick around for historic reasons. For example, there really isn't a great reason for companies to call people DevOps Engineer, but it still happens. I'll take the Solutions Architect role as an example. It's basically sales or customer-oriented developer or technical resource that works with customers to determine what a solution to a problem will look like. "Architect" is mostly meaningless in the sense that Solutions Architects don't really architect much of anything. Usually, they just come up with a plausible path forward and visualize that solution to all the stakeholders involved. This includes travel to customer sites, something that developers are basically never willing or expected to do. They're the folks who deal with the god damn customers so the engineers don't have to. They have people skills, they're good at dealing with people. Yeah, I mean, considering the staff engineer on my team does not shower, there is value in that role. Most of the value in the Solutions Architect is how they're able to work with customers to discover their needs on a more technical level rather than at a high level. Once the plan is determined, the solutions architects don't actually build the solution on their own, they're more like an interface or leader to the development team that builds the solution. https://www.careerexplorer.com/careers/solution-architect/ https://www.careerexplorer.com/careers/solution-architect/ I don't want to put words into your mouth, but maybe you're skeptical of "architects" because they aren't typically expert specialists in one small area. Maybe that's why you don't want to be associate with them. Understandable, perhaps, but don't be misguided into thinking that "architects" aren't skilled professionals who add value to the company. On top of that, I believe they're often paid higher than developers ;-)
alistairSH 5y ago
His logic would apply to tests of all sorts. As long as the dev says the feature is done, that’s the end. And he’s wrong. As teams (or companies, or whatever unit) we get to decide our definition of “Done”. I suggest that definition include appropriate testing. And appropriate code review, which serves two purposes… catching defects and knowledge sharing.
- vinceguidry 5y ago
  In his world, testing the software belongs to a different team than the implementation. Differently managed, differently staffed. Not with engineers, but with testers. It's difficult to say the least to move from testing into engineering And you can't just redefine Agile like that. It's the businesses' money, culture, and productive means. Not yours. If they want teetering software stacks with no thought given to maintainability, managed by non-tech-savvy staff, then that's what their money will buy. We enjoy an environment catering to our needs because our orgs can afford to throw a lot more resources at better managers and better talent. As a result individual contributors can contribute not just tickets, but also to help improve the way we work. Not possible in heavily top-down org structures.
  - Pxtl 5y ago
    In my experience, splitting the testing team out of development materializes refactoring as costly. "What parts of the system did this impact?" "Well, this is a core piece of our ORM config, so... the entire data layer, so from a functional perspective this change impacts every part of the system" "Then you're not changing it, QA can't rerun all their old tests, it would take months, most of those tests don't even work anymore". End result: refactoring never happens. Get it right the first time.
    - vinceguidry 5y ago
      Naturally. In an Agile environment it's more or less impossible to get it right the first time without seriously forward-thinking architecture, which takes time that could be spent pushing harder towards the deadline. It's a business decision to organize software production this way. Refactoring and ease of software maintenance are quality of life issues for engineers. Not business concerns.
ivanhoe 5y ago
That's how a managerial bureaucracy approaches the problem of deadlines: The second it looks like it's working, mark it done and move to the next task, and deal with the bugs later - ideally the manager will move to another position by then due to their exceptional productivity in meeting the set goals, and the bugs will be someone else's problem to solve...
- vinceguidry 5y ago
  If they get solved at all.
skeeter2020 5y ago
>> it breaks Agile It must be "nice" working with an enterprise architect who views agile as a strict, narrowly defined thing.
- vinceguidry 5y ago
  He's really sharp and has keen insight into how enterprise business works. His advice saves us a lot of time and money.
  - throwoutway 5y ago
    But if he wants you to open tech debt tickets, rather than spotting/fixing security issues immediately, this will not save the company time or money.
    - vinceguidry 5y ago
      He doesn't. He was just describing to me the way the enterprise usually sees things. Our shop is more modern than he's used to working in.
yellowstuff 5y ago
Microsoft famously called that process “infinite defects methodology”, and decided it was a bad idea in 1989. "In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix." https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

haggy102 5y ago

Anyone with Architect in their title receives skepticism from me. I've turned down title changes that include it and I refuse to put it on my LinkedIn.

akvadrako 5y ago
Even people designing buildings?
vinceguidry 5y ago
His world seemed completely and utterly divorced from mine. He was deeply connected with big enterprises and how they manage to meet business objectives regardless of not being software engineers themselves. In our world, we take for granted that our managers and leadership are technically proficient. In his, the "Engineering Manager" is a rarity, the people managing engineers are just ordinary managers. Software architecture, in this world, is how you escape the rat race of soulless ticket punching without having to go into management. You use your skills and experience in an advisory role. Obviously there are better or worse architects, I've had the pleasure of working with really good ones. But it often feels like a title and field borne out of a need to retain top talent. (read, not push them away to competitors)
dangus 5y ago
I think that attitude is a little short-sighted, and perhaps a little bit of "anyone that isn't a pure developer is incompetent" elitism. For one thing, titles are just titles, and they stick around for historic reasons. For example, there really isn't a great reason for companies to call people DevOps Engineer, but it still happens. I'll take the Solutions Architect role as an example. It's basically sales or customer-oriented developer or technical resource that works with customers to determine what a solution to a problem will look like. "Architect" is mostly meaningless in the sense that Solutions Architects don't really architect much of anything. Usually, they just come up with a plausible path forward and visualize that solution to all the stakeholders involved. This includes travel to customer sites, something that developers are basically never willing or expected to do. They're the folks who deal with the god damn customers so the engineers don't have to. They have people skills, they're good at dealing with people. Yeah, I mean, considering the staff engineer on my team does not shower, there is value in that role. Most of the value in the Solutions Architect is how they're able to work with customers to discover their needs on a more technical level rather than at a high level. Once the plan is determined, the solutions architects don't actually build the solution on their own, they're more like an interface or leader to the development team that builds the solution. https://www.careerexplorer.com/careers/solution-architect/ https://www.careerexplorer.com/careers/solution-architect/ I don't want to put words into your mouth, but maybe you're skeptical of "architects" because they aren't typically expert specialists in one small area. Maybe that's why you don't want to be associate with them. Understandable, perhaps, but don't be misguided into thinking that "architects" aren't skilled professionals who add value to the company. On top of that, I believe they're often paid higher than developers ;-)

alistairSH 5y ago

His logic would apply to tests of all sorts. As long as the dev says the feature is done, that’s the end. And he’s wrong. As teams (or companies, or whatever unit) we get to decide our definition of “Done”. I suggest that definition include appropriate testing. And appropriate code review, which serves two purposes… catching defects and knowledge sharing.

vinceguidry 5y ago
In his world, testing the software belongs to a different team than the implementation. Differently managed, differently staffed. Not with engineers, but with testers. It's difficult to say the least to move from testing into engineering And you can't just redefine Agile like that. It's the businesses' money, culture, and productive means. Not yours. If they want teetering software stacks with no thought given to maintainability, managed by non-tech-savvy staff, then that's what their money will buy. We enjoy an environment catering to our needs because our orgs can afford to throw a lot more resources at better managers and better talent. As a result individual contributors can contribute not just tickets, but also to help improve the way we work. Not possible in heavily top-down org structures.
- Pxtl 5y ago
  In my experience, splitting the testing team out of development materializes refactoring as costly. "What parts of the system did this impact?" "Well, this is a core piece of our ORM config, so... the entire data layer, so from a functional perspective this change impacts every part of the system" "Then you're not changing it, QA can't rerun all their old tests, it would take months, most of those tests don't even work anymore". End result: refactoring never happens. Get it right the first time.
  - vinceguidry 5y ago
    Naturally. In an Agile environment it's more or less impossible to get it right the first time without seriously forward-thinking architecture, which takes time that could be spent pushing harder towards the deadline. It's a business decision to organize software production this way. Refactoring and ease of software maintenance are quality of life issues for engineers. Not business concerns.

ivanhoe 5y ago

That's how a managerial bureaucracy approaches the problem of deadlines: The second it looks like it's working, mark it done and move to the next task, and deal with the bugs later - ideally the manager will move to another position by then due to their exceptional productivity in meeting the set goals, and the bugs will be someone else's problem to solve...

vinceguidry 5y ago
If they get solved at all.

skeeter2020 5y ago

>> it breaks Agile It must be "nice" working with an enterprise architect who views agile as a strict, narrowly defined thing.

vinceguidry 5y ago
He's really sharp and has keen insight into how enterprise business works. His advice saves us a lot of time and money.
- throwoutway 5y ago
  But if he wants you to open tech debt tickets, rather than spotting/fixing security issues immediately, this will not save the company time or money.
  - vinceguidry 5y ago
    He doesn't. He was just describing to me the way the enterprise usually sees things. Our shop is more modern than he's used to working in.

yellowstuff 5y ago

Microsoft famously called that process “infinite defects methodology”, and decided it was a bad idea in 1989. "In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix." https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...