3 ms·

My company has quite a few IT architects (the "senior" ones are the worst). They always accuse you of "solutioning" when you propose something, drag you through

My company has quite a few IT architects (the "senior" ones are the worst). They always accuse you of "solutioning" when you propose something, drag you through weeks of meetings, produce a lot of documents and when they are done, they either do nothing or propose a "beautiful" solution that only works on paper. After going through this a few times I have concluded it's easier to whip out a few prototypes for different aspects of the project. This allows you to understand the problem better while also exploring workable solutions. Often you don't understand the problem but you also don't understand ways to solve them well either and need to do some learning. You just shouldn't fall into the trap of thinking that once the prototypes work, they are ready for production. Sometimes I wonder if it should be mandatory to scrap that code and start from scratch to development real solution.

tooltower 5y ago
Iterating can take many forms, and different teams have different workflows. For my work, I would rarely be able to make a "quick prototype" even if I wanted to, since most of my projects need to modify other people's code. And they have to be deployed to be validated. In those cases you better have some consistent plan that everyone agrees on before anybody else lets you touch code that they are responsible for. Yes, you can still make mistakes and iterate, but you need to plan for those too. But I agree with you if you can prototype with a fresh body of code, not touching shared repositories.
- kqr 5y ago
  If your quick prototypes as a rule require complex interactions with other team's services, the problem is your architecture. Try to find the smallest step toward an architecture that allows you to prototype in relative isolation. Take that and repeat. Yes, prototypes have to be deployed. That goes for everyone's prototypes. That's how you get feedback on them. If it's a big deal that you have to deploy your prototypes, find the smallest step you can towards deployments that are less of a big deal and take it. Then repeat. Paper engineering is never better than just trying out the thing in the real world. Most engineering professions have transaction costs that make this impossible. We have the ability to lower those transaction costs, if we just make the right effort. Come on, do it! It will be fun. (And "that doesn't work here" has been debunked so many times. It does work also for you.)
hinkley 5y ago
> You just shouldn't fall into the trap of thinking that once the prototypes work, they are ready for production. That is a huge “just” and painfully laughable when many of those architects were young men. The industry was practically incapable of looking at software that looks like it should work and declaring victory. Not just to the level of trope, but to the level of trauma. It was fucking brutal. But we haven’t solved this problem, we’ve just gotten really good at avoiding that situation (eg, CI/CD). That fence is there for a reason, don’t remove it. “Solutioning” is just corporate buzz phrase for the XY problem. I threw away a day’s worth of code yesterday because I realized at the last moment that I was solving the wrong problem, literally as I was writing the summary for the PR. We have to do A because of B, and we can’t change B because of… umm, why can’t we change B? Because I didn’t understand all the consequences of B the last time I faced a related problem. But now I do, and it’s fairly arbitrary if I fix the error handling in two methods and a couple of tests, OK. Every line of code you write has to be maintained forever. Most of the ones you delete do not. A few have to be added back in later. Big whup.
eyelidlessness 5y ago
At least in my working history “prototype” is explicitly designated for the trash heap. Everything up to that point in your description sounds really good. Just… file your learnings, put all of the materials that lead to your findings in a graveyard, and make digging graves exactly that much effort.

tooltower 5y ago

Iterating can take many forms, and different teams have different workflows. For my work, I would rarely be able to make a "quick prototype" even if I wanted to, since most of my projects need to modify other people's code. And they have to be deployed to be validated. In those cases you better have some consistent plan that everyone agrees on before anybody else lets you touch code that they are responsible for. Yes, you can still make mistakes and iterate, but you need to plan for those too. But I agree with you if you can prototype with a fresh body of code, not touching shared repositories.

kqr 5y ago
If your quick prototypes as a rule require complex interactions with other team's services, the problem is your architecture. Try to find the smallest step toward an architecture that allows you to prototype in relative isolation. Take that and repeat. Yes, prototypes have to be deployed. That goes for everyone's prototypes. That's how you get feedback on them. If it's a big deal that you have to deploy your prototypes, find the smallest step you can towards deployments that are less of a big deal and take it. Then repeat. Paper engineering is never better than just trying out the thing in the real world. Most engineering professions have transaction costs that make this impossible. We have the ability to lower those transaction costs, if we just make the right effort. Come on, do it! It will be fun. (And "that doesn't work here" has been debunked so many times. It does work also for you.)

hinkley 5y ago

> You just shouldn't fall into the trap of thinking that once the prototypes work, they are ready for production. That is a huge “just” and painfully laughable when many of those architects were young men. The industry was practically incapable of looking at software that looks like it should work and declaring victory. Not just to the level of trope, but to the level of trauma. It was fucking brutal. But we haven’t solved this problem, we’ve just gotten really good at avoiding that situation (eg, CI/CD). That fence is there for a reason, don’t remove it. “Solutioning” is just corporate buzz phrase for the XY problem. I threw away a day’s worth of code yesterday because I realized at the last moment that I was solving the wrong problem, literally as I was writing the summary for the PR. We have to do A because of B, and we can’t change B because of… umm, why can’t we change B? Because I didn’t understand all the consequences of B the last time I faced a related problem. But now I do, and it’s fairly arbitrary if I fix the error handling in two methods and a couple of tests, OK. Every line of code you write has to be maintained forever. Most of the ones you delete do not. A few have to be added back in later. Big whup.

eyelidlessness 5y ago

At least in my working history “prototype” is explicitly designated for the trash heap. Everything up to that point in your description sounds really good. Just… file your learnings, put all of the materials that lead to your findings in a graveyard, and make digging graves exactly that much effort.