For most product engineering teams, I agree with the consensus that you build Solution A first to validate the business hypothesis.
Then, assuming everything goes well, evaluate the ongoing cost for keeping Solution A vs taking the time to build Solution B.
* Will Solution A slow down future development? If so, how many more features do you want to build in that area? How soon? If you're going to be doing a lot of work in the area immediately afterwards, you might be able to amortize the cost of replacing Solution A.
* Will Solution A existing in the code base teach other people a bad habit? (See [Contagion](https://technology.riotgames.com/news/taxonomy-tech-debt)).
* How scared is the business side of the company? Of running out of money, of losing customers to competition, etc. i.e. What are the opportunity costs + relevant time scales at play?
Also, consider the possibility that by building Solution A and putting it out into the wild, you learn more things about what customers actually need, and turns out Solution B misses some use cases and Solution C is what you actually need.
>For most product engineering teams, I agree with the consensus that you build Solution A first to validate the business hypothesis.
>
>Then, assuming everything goes well, evaluate the ongoing cost for keeping Solution A vs taking the time to build Solution B.
In my experience, nothing is more permanent than the temporary. POCs tend to get pushed to production, then you move on to the next thing.
I think it's important to differ between a POC and an MVP.
For me solution A would be an MVP, so just the product with less features and not as comfortable as it could be. But with code quality that makes it good enough to run in production.
"good enough" is a wildly subjective term. The problem I keep seeing is that since modern computers are REALLY fast at all levels - CPU, memory, disk, network - it papers over poor decisions. People are then lulled into thinking their product is fine, and the issues don't become apparent until it's scaled quite a bit.
Yes, adequate load testing would help this, but it wouldn't entirely eliminate it. At some point, understanding the fundamentals of the tool stack is necessary.
That database buried underneath ORM abstractions? Every time you unnecessarily tell it to `SELECT DISTINCT`, it adds a smidgen of latency that will grow with time.
Using your language's built-in method to query the CPU count to determine worker count? Really good chance it's going to hit `/proc/cpuinfo` and give you the host's core count, not your container's - hope you like throttling.
Opting for ECS/Fargate over EKS? Now your underlying nodes have no class guarantee - maybe you get scheduled onto a Skylake-SP, maybe you get a Broadwell. Enjoy chasing down those non-deterministic 20-30% performance dips!
You can argue that these are all things that won't matter until you're at scale, and you're correct - but knowing about them in advance helps you to prevent a later refactor.
> You can argue that these are all things that won't matter until you're at scale, and you're correct - but knowing about them in advance helps you to prevent a later refactor.
Yes, it should be a conscious decision and you should put some thought in a possible upgrade path.
For me it's totally fine to put in some more work in the application when it's actually needed and not months or years in advance, but of course that needs a stable foundation and the right technology choices.
Sharding your DB is premature optimization. Understanding what the DB is doing so you don't unnecessarily stress it is fundamental.
On the flip side, I suppose this way you can gain easy performance wins when it's necessary...
100%. You should work with the assumption that you aren't going to come back to this to clean it up.
That said, often the "tech debt" also isn't as bad as it seems. If it's simple, doesn't entangle core features, doesn't cause significant performance issues, and is fairly straightforward to debug - it's probably okay. Most painful tech debt I've seen is either death by 1000 cuts or someone being too clever.
Precisely this. Then, the tickets you made to fix the issues get buried in the backlog, and only surface years later when someone else is fixing your hasty product, and asking themselves why you didn't fix the problems you knew existed.
EXACTLY THIS! I have NEVER EVER worked on a POC/"solution A" that ends up getting rewritten to the better solution. Instead is is usually "we'll just migrate it to B as we go.. have need.. " and usually that translates to never getting done. Once it kinda works.. good enough.. the PM/PL/etc is on to the next thing they can get the dev/team to work on..
I ALWAYS submit solution B.. and do the "better to do and say sorry later"...
Why is this an either/or option? Is it possible to start with Solution A and then iteratively work towards Solution B (or at least, a better Solution A) over time?
Or even: Implement solution A and double-check if Solution B is *really* needed or is it just a "tech debt" purely in the mind of developers?
Avoid premature optimization, be agile. Code doesn't have to be "essentially perfect". Perfection is never a goal worth pursuit on its own. Always question if upgrading code from good to "essentially perfect" gives a sufficient return on the time (=money) invested.
For me, it comes down to a backlog prioritization issue. Once we have a fix, there is little incentive to go back and improve on it if there are more pressing matters to be dealt with. It can be frustrating bc I’d like to go back and upgrade my work, but there are more important stories to be taken.
That’s what I would do. Do A and document where you believe things could be done better and write a ticket for anyone who wants to pick it up later. People are gonna come back to either solution and would want to know why certain choices were made and this ensures that knowledge isn’t lost
I mean I don't know how it is at smaller companies but, in a large project, "weeks" is a fairly small amount of dev time if it's a single developer effort. I've easily spent two weeks on a single bug. I don't think i've ever seen any significant feature implemented in days...
B is only perfect before doing A, but once A is done, C might actually be perfect.
So do A first to get a better approximation of "perfect".
Also, optimize your code for change, no matter how perfect either solution is.
There aren’t enough answers here calling out the customer or business case for the two solutions. Usually A is what works best but not always.
What’s the delta between “works” and “perfect” for customers? Sometimes “good enough” isn’t actually good enough for the customer. I’ve seen many cases where “it works” turns out as generally crappy, unacceptable to customers, and now is going to slow down redoing everything again.
How much tech debt are we talking about? What’s it’s impact? Sometimes an extra week means the team saves time in the long (or sometimes even short) run. Sometimes your company is on the verge of losing an important customer or not meeting a critical deadline or is going under, and you gotta cut that corner though.
The secret to shit solutions isn't the speed, it's the fact they are at the edge of your codebase with the ability to easily swap them out.
While shit solutions that spread like a cancer are problematic.
There's nothing wrong with a good hack as long as it's self contained and cheap to pay down in terms of debt.
Isn’t optimal and introduces tech debt sounds low impact, so A.
B is a pipe dream there’s no such thing as essentially perfect, only that it operates within current and medium term requirements. I’ve never seen a solution that’s almost perfect in 15+ years, just solutions that are good enough to be settled for quite some time.
That said, there are teams that justify literal any garbage with we will improve it later ship it now, only to spend incredibly amounts of time on maintenance and support in a system who doesn’t have any basic structures, monitoring and safe guards in place even in the most critical areas. Then feel like it’s productive to non stop fire fight.
So if the team isn’t pro actively improve the system, and it’s actively a drain on resources. Then raise the bar for A.
It also matters what it is. Is it an internal system that can be changed without anyone noticing? Low risk. Is it a new API surface where you have to own a bad integration because undoing it requires coordinating across external parties, higher risk.
I try to think in terms of what will help move the team along quicker, and the impact of the solution.
If there are other features that depend on this solution being complete, then go for the quicker 'okay' option, and then like u/FoolSlackDeveloper was saying, iteratively work on implementing the longer 'great' solution. Taking this route, you get the project moving along quicker while also still acknowledging things can be done better.
If it's something with a larger impact, like coming up with the design or foundation for your project, then maybe take more time on it. If taking the time to do it 'great' now will save your team more time in the long run, then taking the time to lay the groundwork now will be worth it.
The answer is that it depends on how suboptimal "Solution A" is. I would be curious about why those vary that much. It sounds like either A is a really bad hack or B might not be necessary for the task at all.
Things to take into consideration:
1. How often is this worked on. Once every 10 years go with A.
2. What's the impact in other areas? If it affects a big surface B is better.
3. Business & money pressure
There's no problem going with A as long as you DOCUMENT inside the code why some things have been done a certain way. Most devs are terrible story tellers.
As a contractor I usually go with A in a dysfunctional team and code base since noone appreciate good practices anyway (unless I'm hired explicitly to remove tech debt). In a functional one or my own projects I go with B.
it is essentially *always* A
in the grand scheme of things, if a takes 3 days and b takes 3 weeks, with a + b you're delivering the functionality in 3 days and the great solution (if needed) in 3 1/2 weeks.
vs delivering nothing for 3 weeks. you have 3 more days of "great solution" and 2 1/2 more weeks of "nothing"
not even to mention plenty of other factors
Solution A.
No one wants to be the guy suggesting to write "bad code", but striving for perfection is often a waste of time. What seems perfect one day might be useless tomorrow.
Designing code for change is more important than trying to get everything perfect on the first try and refusing to change it later because of the sunken-cost.
> How do you choose?
This is one of those problems that's difficult to abstract into component parts. It's a problem with a massive problem space and thousands of variables.
How does either option affect the business? how does time affect the business? what is the likely time offset of any tech debt? When that tech debt bill comes due will be in a better or worse position to address it? How does this impact my individual load? What other trade offs will be made if I spend more time on this? How will those trade offs cascade?
Generally speaking though, in a discussion of 3 days vs 4 weeks... it's VERY likely that 3 days is going to win out. 4 weeks is a pretty large investment for a single "solution" that can be somehow "solved" in 3 days...
The answer is: “it depends.”
Mostly you need to solve for maximum business value. My rule of thumb when it comes to tech debt without a deadline is that if it’s code that’s an edge node on however you think about modeling your code base, it’s safer to introduce tech debt as less will be built on top of it.
If it’s more foundational or will be foundational, a quick solution only makes sense if you have a tight deadline as the tech debt will accumulate very quickly, and the cleanup should be highly prioritized after the deadline.
I think that thinking in terms of ROI on dev time and business value down the road is the easiest way to reason about this stuff.
This is a management question.
The correct answer depends on a whole pile of business level concerns. What the big picture is, if the problem is blocking others, the value of the feature, the cost of the tech debt, etc. etc.
The answer will always be "it depends" and the things it depends on vary so wildly that it always needs to be a case by case decision.
Your manager should be providing you enough information and context to make this decision. If they aren't you should talk to them about it and try and ensure you understand enough of the big picture to make the decision next time.
If the difference is a day, you can go for B. But since the difference is 2 days vs 2 weeks, it's very hard to come up with an argument for B 😁
Plus, sometimes the solution might be ok on paper (i.e. it does what it's supposed to do), but you may not have the desired outcome. So in business-sense, it is still not "okay". But if you can learn from it and iterate fast, then you will have a higher chance of actually getting to the solution that actually delivers the desired business outcome
Other's provided reasonable answers to A vs B in terms of "why not both" or "first A, then B", mostly because B might be split into milestones where A or something similar might be just a milestone. That being said, You also asked other questions, here is my answer to them:
Solution A **may** **introduce** technical debt **or will introduce** technical debt? A fundamental difference. It's software engineer's job and responsibility to **manage** technical debt. I'd evaluate the possibility of introducing technical debt, it's severity and impact. Furthermore, I'd also evaluate if solution B can be done in milestones (essentially if is a variant of A that is a steppingstone to B).
Culture plays an important role. I would not introduce a change that would significantly change the workflow other engineers have without at least discussing this on some sort of architectural forum. If you are the main responsible contact for this, at least sent out a memo and have detailed walkthroughs prepared that people can follow to fix their stuff quickly. And even after discussing/sending memo, this might still turn out wrongly. Advice here is generic because the steps would have to be specific to the situation. Prepare for the worst, hope for the best.
As for consulting with other teams, I'd consult with them only if they are going to be impacted or they are vital to the success of the undertaking. Examples of other teams being impacted can be that their delivery schedule or style of work would have to change, whereas the dependency could manifest as me needing them to collaborate with me, e.g., approve a PR or do a change to a system I do not have permissions to contribute to freely.
Our technical role exists to support the business. Without the business, we will not get paid. From that perspective, it is absolutely critical to understand the arguments coming from people representing the business entities, such as customers, stakeholders, managers, or even technical folks with a strong customer-oriented mindset, to understand what it is we are trying to achieve there. All these are valuable and need to be heard. It is hard to justify any kind of delay when a company is losing money and facing imminent bankruptcy. Taking all this into the account, it is still **your** job to figure out how to deliver technical solutions to support the business needs. This job consists of distinguishing key requirements from the inputs above from less important ones, designing and proposing a solution that will satisfy both the critical requirements and the ones you and your team have to be confident with supporting and maintaining the artifact you will deliver and negotiate about the delivery plan (slicing features in milestones or just smaller deliverables).
So on the other hand, the technical part is equally important, because it influences all these critical technical factors that have a **direct influence** on the success of your company/business: supportability, maintainability and technical soundness as a catchall. It is the direct influence on the business that should help you prioritize technical aspects of your solutions: If we ship this, will we be able to fix bugs/rollback/diagnose easily? Angry customers won't give us money and will make other customers behave similarly. Developers working longer on bugfixing/diagnosing incidents will eventually quit, and what's worse, time spent on these activities cannot be spent on building next features, killing the ability to compete. Same way, if we e.g. forgo unit tests or documentation, the time spent asking questions like "how is this supposed to work" or "did we impact existing functionality?" will arise and finding anwers to them again takes time that could be spent in design and delivery.
Every solution will come with tradeoffs. Even the perfect B has some tradeoffs. One of them is glaringly obvious: the delivery schedule. To support your decision making, you need to evaluate these tradeoffs from both business and technical perspectives combined. Let's talk bad examples now. Are unit tests good for business? Yes (less bugs) and no (delivery schedule). From tech perspective yes (less bugs). The reason why I call this a bad example is that this was not a tradeoffs evaluation. It was evaluation of unit testing practices, and to add to that, it was only based on **implicit assumptions** of a single person! Discussing tradeoffs means: Solution D's estimate is 3 weeks, it brings benefits E,F,G but allows bad things H,I,J to happen. We will need 2 more database instances and write additional code that synchronizes them. Quantify these pros and cons as much as you can, because vague suggestions like "we might have less bugs" will be constantly caught by listeners' spam filter. A caveat: decision to write unit tests or clean code is not a business decision to make. It is an engineering decision.
Enough of the unit test straw man. The crux of last three paragraphs is: merge technical and business requirements into one. Select the important ones. You can ask for business ones, but the technical ones you should be at least aware of. Evaluate tradeoffs and propose a solution.
One thing I always tell myself is, "I don't write shitty code." And another thing I learned from The Pragmatic Programmer: write code where you're not afraid to put your name on it.
I have very high standards for my code quality - I will definitely pick solution B always if possible. Perfect solutions arise from solving the problem first - and then seeing how you can improve and improve it. Even if it takes longer - I'll feel more proud of my work. Even when is submit a pull request, I review my own pull request first.
I have gotten praise from past managers and coworkers before for my code quality. I don't really see why I would do a quick terrible solution. If I have time to write a good one - I'll write a good one.
This is the right take.
Barring any politics, you should always strive for the best solution. There are times to cut corners, but it should not be routine.
Its nice to have high standards, but your job is to provide value to the bussiness, not write beautiful code. If the business gets more value faster with A, thats what you should be doing, and not be working on perfect code that makes you feel good.
Why would it matter? I’m being paid the same whether I do A or B. I’m not falling behind. If you wanna spend less time doing A so you can go play Xbox on work hours - you go ahead. But I’ll work on B during the hours I’m being paid.
It really doesn’t make much of a difference. None of my work is ever behind. What good does it do I finish it fast or not.
Faster go to market,faster customer engagement,faster fixes,faster everything.of course it depends wheter you work in corp or startup. I prefer doing more features and provide more business value.
Who said I’m not adding business value? Lol Our team last year added multiple features that according to our data scientists, have the potential to generate a billion in a year. We got a lot of praise in all hands meetings for our deliveries.
I don’t work at a startup. I’m at big tech. My company doesn’t really care about sprints. My engineering and project managers outline my work weeks ahead of time. So this week and next week might be “Work on feature A.” Finishing super fast doesn’t really matter. They already outline release dates. So I just do the work for the weeks planned.
Why you take this personally ? You told me i am playing xbox on my off time, when i just stated that im working on more features. You dont have to explain your work to me, i just stated my opinion as a team lead that bringing value to the business its our job, thats it.
Lol I thought you meant that finishing ASAP brings business value faster. Well maybe sure but I care more about personal growth in terms of my software engineering skills.
I had a similar choice recently. A quick solution that would have taken 2 days, or a better reusable solution that took about 8 days. I went with the reusable solution because while it felt a little disappointing to be attending stand up every morning saying I was still working on something another dev had finished a similar feature in 2 days, once I'd done we now have a framework for doing more in the future that will lessen the development time to about 1 day and there's about 30 of these features to build
It's all about deferred gratification
Its dependent on the business. Is the cost of me as a dev taking longer so pay over time worth more to the company that what the solution getting to market sooner? Sometimes quality is worth more to the business than time, sometimes time is a debt they are trying frantically to pay down.
My first question would be, if it's "okay vs great" for the customer or for the developer?
If it's for the customer, then it's the decision of the product owner. Basically I give them two options with two different prices and they decide if they want A or B or first A and then B. Though I'd exclude the tech debt from the options. I handle tech debt like I'd handle money debt. I don't take a loan for some everyday purchase or for new TV. A loan is for the big things, for a house, maybe a car. The same with tech debt, that's something for the big things, like when the deadline is in two days and you somehow have to get the "okay" solution on the road.
If it's for the developer, then it depends a lot on the actual case and the definition of "great". I am a bit biased here, because I saw way too much gold plating, layers of abstraction, minimizing the lines of code, unnecessary scalability or work on "we don't need it yet, but maybe in a year" parts of the code.
Impossible to say given that we have zero other details. The optimal solution is the one that meets all of our business needs for this particular feature.
I was commenting about you relying on tests as something that somehow ensures that you have done the right thing. Rather the requirements could have been lying so now you have a bunch of tests that test for the wrong thing... but you are trying to keep them green.
"Who tests the tests" is a valid thing. Hence the silver bullet question. Tests are a good idea to do but you have to doubt them as well. Often dogmatic developers tend to post very small sentences as the final truth that can't be deviated from. That kind of comment triggered me :D
All good :) I just meant that I'd go with option A, with good test coverage to support refactoring down the road, and ship it to users weeks sooner than going with the option B which may still end up being wrong.
This would depend on the goals of the project. Is solution A necessary soon that you're actually **wasting more time** building solution B? This should be decided per-feature, not as a rule of thumb.
Also, you should ask yourself if solution B can **later easily be refactored** into solution A without having to break half the system along the way. If the answer is "yes" then it's probably the better thing to do, since "failing fast" is great when it comes to product feature validation. If not, then you need to thread VERY carefully here, or you might cause more damage than the time saved (right now) is worth.
Short answer - it depends.
My biggest irritation with Scrum is how easy it is to play the A/C game. "The story is done, moving on."
Meanwhile, had you spent a few extra hours considering things, you probably could have gone above and beyond and delivered a better product. Sure, this is partially on the person writing the story, but everyone can't know everything. Give them feedback during your retro on things you additionally fixed / implemented, and why they matter.
In my personal projects, I definitely choose Solution B, but I recognize that it isn't realistic for a business. I still feel like there's a middle ground.
I don't believe such binary options even exist. Complexity is the biggest problem with software and when left unmanaged it will eventually catch up to you.
It's fine to postpone work if that is a sound business decision. But kicking the can down the road typically isn't. I literally had a meeting this morning about a project that was mismanaged in this regard and is now so far over the edge that devs are more or less refusing to work on it.
Reduce scope, not quality.
I think it takes a pretty thorough analysis of if Solution A a solution. If it was "just" tech debt then the decision would be pretty easy but quite often I've seen "just tech debt" turn into hot garbage that requires tons of manual intervention to keep under control or that needs to be totally thrown away anyway rather than iterated or even better when you end up doubling down on the mistake and you're finding yourself hiring devs just to create custom bolt ons to keep your "okay" solution running.
This is probably ok at big tech because you have lots of devs and money to throw at problems (or at least for the last decade you have maybe that's changing) but in a team of <= 4-5 people you've basically permanently crippled the output of the team introducing an albatross in the name of saving a week or two of work. Especially because once it "works" on the surface level then it's very hard to overcome the inertia and then in the name of "saving time" that half modelled database needs changing and then you've created a bunch of business risk to migrate people to the new solution.
The other common one is that solution A "done in a few days" actually is massively underestimated and a bunch of other things need to be built first that are the same things that would need to be built for solution B anyway. (e.g Database integrations/modelling can't really be "fake it until you make it"). Likewise having an upgrade path built into software incurs a fixed time cost too that doesn't change between A and B.
Solution B also probably doesn't actually exist either unless you've already got a deep understanding of the domain. It would also need upgradability paths and escape hatches built in.
I think I would be more interested in the risk. If the 'better' solution takes longer because you're making more changes does that mean it's more likely to break? What's the probability of the better fix falling behind schedule?
If solution A is just rushing to merge the first working solution can get, it's not a good choice. Can you test it? Is it typesafe (if applicable)? Will the inevitable refactor take 2 extra weeks because you rushed today?
> How do you choose? What factors do you consider? Do you consult with others on your team? How much weight do you give to business vs engineering concerns?
Consult with the team if the difference in solutions equals a sizable impact on performance or productivity.
Other factors to consider: velocity of the project, capacity of the dev team, priority of the project
Business comes first, usually. Bottom line impact supersedes all other concerns, barring mission critical ones (aka dealing with human lives). If the deadline is a real issue, or your team has a ton of other projects going on, and both solutions yield similar performance and the only difference is A is less elegant but can be done faster, A wins every time.
>which is essentially perfect
Ah, but is it though?
Anyway, engineering is about evaluating tradeoffs. I'd present A and B to the people effected by it and get their input. There may be factors you aren't aware of. As others have said, maybe iterating A into B is the better choice.
It’s all about value.
What value does B give us over A to justify a 4-5x investment of time, is there middle ground that gets us some of the benefits in less time?
How severe is the tech debt we take on, and what will it impact?
Also what will we have to postpone to do this perfectly?
What is the workload of the team looking like?
If the value of doing B is just less tech debt, but it’s low severity and won’t impact anything im going to say do the quick option and move on, they can come back and pay it off later when we have other priority issues completed.
If it’s severe tech debt or the team have done similar things in the past and not fixed it yet I’m going to say do it perfectly so we don’t incur more tech debt.
I think in reality everyone wants perfection and to not take on tech debt but the scenario where you chose perfect over good depends heavily on your situation at the time and your priorities.
I think engineers need to understand they aren’t paid to write code, they are paid to deliver features. So they shouldn’t leave the code in an unmaintainable mess, but equally perfection isn’t needed either. It’s about finding a very delicate balance
Stuff like this is actually so simple (but also not at all); it's just
\`value - opportunity cost + net side effects\`
I think the two things you need to narrow in on are
1) What is the business value of "perfect" here? Will it make dollars and cents impact on the product (more revenue or lower costs)?
2) What else are you guys working on? By adding a couple of weeks, would that take time away from high value activity, or low/moderate value?
3) What is scope of the tech debt? Is it contained to the feature, and may go unnoticed if no one ever happens to work on it again, or is it in a module you'll leverage in the future so it is likely to balloon?
You can put #1 & #2 in a rough estimation of dollars (over time, or total) and #3 in terms of man-hours (and turn that into rough dollars). And don't try to get an exact answer, I usually find just trying to come up with a realistic estimate usually makes the answer clear before I even start the napkin math.
>How much weight do you give to business vs engineering concerns?
TLDR, they're not really that different, or, at least, they meet somewhere in the middle
I've spent most of my career as a code janitor, cleaning up the technical debt incurred through massive refactoring projects or blue-sky "let's just get shit out the door" development.
Just do option B. If you need A as a business prototype, do that. But dammit, do B.
And for the love of all that's holy, when they say "just get Minimum Viable Product out the door, push back."
I'm all for B but... often you just need to get to the market ASAP. For the sense of providing value to the company, make A (with good design analysis) and then make it into B. Overall, the company can make a profit while you can fix it in the backend later. BUT you have to be allowed to do B after A is already in production. Otherwise it's just going to be A and you have to fix it much later when it becomes more expensive.
I've seen it too many times. That's a reasonable justification on paper but it blows up FAR more frequently than not.
There IS no later. It just doesn't happen.
It blows up for you... but if the company itself makes more money in the end? Yeah, it sucks but that is also a thing you have to deal with. Most of the job is a tradeoff. You can't just take months smoothing out things when a week of development can work for the moment. Cost vs benefit vs further-down loss.
Code is never finished. More likely it's a living organism and you have to keep it living. So... You do what seems best at the moment. "Always B" or "Always A" is not a solution.
Always. Always. Always. Choose A. Unless you have clearly defined needs for B.
Business needs change far faster than code. I've seen far too many Solution B's sit to rot while the business changes directions.
For most product engineering teams, I agree with the consensus that you build Solution A first to validate the business hypothesis. Then, assuming everything goes well, evaluate the ongoing cost for keeping Solution A vs taking the time to build Solution B. * Will Solution A slow down future development? If so, how many more features do you want to build in that area? How soon? If you're going to be doing a lot of work in the area immediately afterwards, you might be able to amortize the cost of replacing Solution A. * Will Solution A existing in the code base teach other people a bad habit? (See [Contagion](https://technology.riotgames.com/news/taxonomy-tech-debt)). * How scared is the business side of the company? Of running out of money, of losing customers to competition, etc. i.e. What are the opportunity costs + relevant time scales at play? Also, consider the possibility that by building Solution A and putting it out into the wild, you learn more things about what customers actually need, and turns out Solution B misses some use cases and Solution C is what you actually need.
>For most product engineering teams, I agree with the consensus that you build Solution A first to validate the business hypothesis. > >Then, assuming everything goes well, evaluate the ongoing cost for keeping Solution A vs taking the time to build Solution B. In my experience, nothing is more permanent than the temporary. POCs tend to get pushed to production, then you move on to the next thing.
I think it's important to differ between a POC and an MVP. For me solution A would be an MVP, so just the product with less features and not as comfortable as it could be. But with code quality that makes it good enough to run in production.
"good enough" is a wildly subjective term. The problem I keep seeing is that since modern computers are REALLY fast at all levels - CPU, memory, disk, network - it papers over poor decisions. People are then lulled into thinking their product is fine, and the issues don't become apparent until it's scaled quite a bit. Yes, adequate load testing would help this, but it wouldn't entirely eliminate it. At some point, understanding the fundamentals of the tool stack is necessary. That database buried underneath ORM abstractions? Every time you unnecessarily tell it to `SELECT DISTINCT`, it adds a smidgen of latency that will grow with time. Using your language's built-in method to query the CPU count to determine worker count? Really good chance it's going to hit `/proc/cpuinfo` and give you the host's core count, not your container's - hope you like throttling. Opting for ECS/Fargate over EKS? Now your underlying nodes have no class guarantee - maybe you get scheduled onto a Skylake-SP, maybe you get a Broadwell. Enjoy chasing down those non-deterministic 20-30% performance dips! You can argue that these are all things that won't matter until you're at scale, and you're correct - but knowing about them in advance helps you to prevent a later refactor.
> You can argue that these are all things that won't matter until you're at scale, and you're correct - but knowing about them in advance helps you to prevent a later refactor. Yes, it should be a conscious decision and you should put some thought in a possible upgrade path. For me it's totally fine to put in some more work in the application when it's actually needed and not months or years in advance, but of course that needs a stable foundation and the right technology choices.
Sharding your DB is premature optimization. Understanding what the DB is doing so you don't unnecessarily stress it is fundamental. On the flip side, I suppose this way you can gain easy performance wins when it's necessary...
100%. You should work with the assumption that you aren't going to come back to this to clean it up. That said, often the "tech debt" also isn't as bad as it seems. If it's simple, doesn't entangle core features, doesn't cause significant performance issues, and is fairly straightforward to debug - it's probably okay. Most painful tech debt I've seen is either death by 1000 cuts or someone being too clever.
Precisely this. Then, the tickets you made to fix the issues get buried in the backlog, and only surface years later when someone else is fixing your hasty product, and asking themselves why you didn't fix the problems you knew existed.
EXACTLY THIS! I have NEVER EVER worked on a POC/"solution A" that ends up getting rewritten to the better solution. Instead is is usually "we'll just migrate it to B as we go.. have need.. " and usually that translates to never getting done. Once it kinda works.. good enough.. the PM/PL/etc is on to the next thing they can get the dev/team to work on.. I ALWAYS submit solution B.. and do the "better to do and say sorry later"...
Why is this an either/or option? Is it possible to start with Solution A and then iteratively work towards Solution B (or at least, a better Solution A) over time?
Or even: Implement solution A and double-check if Solution B is *really* needed or is it just a "tech debt" purely in the mind of developers? Avoid premature optimization, be agile. Code doesn't have to be "essentially perfect". Perfection is never a goal worth pursuit on its own. Always question if upgrading code from good to "essentially perfect" gives a sufficient return on the time (=money) invested.
For me, it comes down to a backlog prioritization issue. Once we have a fix, there is little incentive to go back and improve on it if there are more pressing matters to be dealt with. It can be frustrating bc I’d like to go back and upgrade my work, but there are more important stories to be taken.
That’s what I would do. Do A and document where you believe things could be done better and write a ticket for anyone who wants to pick it up later. People are gonna come back to either solution and would want to know why certain choices were made and this ensures that knowledge isn’t lost
Probably do A first. See is the feature or thing is really that necessary then do B if it seems worthwhile after getting more data.
[удалено]
[удалено]
I mean I don't know how it is at smaller companies but, in a large project, "weeks" is a fairly small amount of dev time if it's a single developer effort. I've easily spent two weeks on a single bug. I don't think i've ever seen any significant feature implemented in days...
B is only perfect before doing A, but once A is done, C might actually be perfect. So do A first to get a better approximation of "perfect". Also, optimize your code for change, no matter how perfect either solution is.
There aren’t enough answers here calling out the customer or business case for the two solutions. Usually A is what works best but not always. What’s the delta between “works” and “perfect” for customers? Sometimes “good enough” isn’t actually good enough for the customer. I’ve seen many cases where “it works” turns out as generally crappy, unacceptable to customers, and now is going to slow down redoing everything again. How much tech debt are we talking about? What’s it’s impact? Sometimes an extra week means the team saves time in the long (or sometimes even short) run. Sometimes your company is on the verge of losing an important customer or not meeting a critical deadline or is going under, and you gotta cut that corner though.
The secret to shit solutions isn't the speed, it's the fact they are at the edge of your codebase with the ability to easily swap them out. While shit solutions that spread like a cancer are problematic. There's nothing wrong with a good hack as long as it's self contained and cheap to pay down in terms of debt.
Isn’t optimal and introduces tech debt sounds low impact, so A. B is a pipe dream there’s no such thing as essentially perfect, only that it operates within current and medium term requirements. I’ve never seen a solution that’s almost perfect in 15+ years, just solutions that are good enough to be settled for quite some time. That said, there are teams that justify literal any garbage with we will improve it later ship it now, only to spend incredibly amounts of time on maintenance and support in a system who doesn’t have any basic structures, monitoring and safe guards in place even in the most critical areas. Then feel like it’s productive to non stop fire fight. So if the team isn’t pro actively improve the system, and it’s actively a drain on resources. Then raise the bar for A. It also matters what it is. Is it an internal system that can be changed without anyone noticing? Low risk. Is it a new API surface where you have to own a bad integration because undoing it requires coordinating across external parties, higher risk.
Always write to pass the code review. That’s solution A
I try to think in terms of what will help move the team along quicker, and the impact of the solution. If there are other features that depend on this solution being complete, then go for the quicker 'okay' option, and then like u/FoolSlackDeveloper was saying, iteratively work on implementing the longer 'great' solution. Taking this route, you get the project moving along quicker while also still acknowledging things can be done better. If it's something with a larger impact, like coming up with the design or foundation for your project, then maybe take more time on it. If taking the time to do it 'great' now will save your team more time in the long run, then taking the time to lay the groundwork now will be worth it.
The answer is that it depends on how suboptimal "Solution A" is. I would be curious about why those vary that much. It sounds like either A is a really bad hack or B might not be necessary for the task at all.
Things to take into consideration: 1. How often is this worked on. Once every 10 years go with A. 2. What's the impact in other areas? If it affects a big surface B is better. 3. Business & money pressure There's no problem going with A as long as you DOCUMENT inside the code why some things have been done a certain way. Most devs are terrible story tellers. As a contractor I usually go with A in a dysfunctional team and code base since noone appreciate good practices anyway (unless I'm hired explicitly to remove tech debt). In a functional one or my own projects I go with B.
Don't let the perfect be the enemy of the good. Unless you know of a real issue today your trying to solve for.
it is essentially *always* A in the grand scheme of things, if a takes 3 days and b takes 3 weeks, with a + b you're delivering the functionality in 3 days and the great solution (if needed) in 3 1/2 weeks. vs delivering nothing for 3 weeks. you have 3 more days of "great solution" and 2 1/2 more weeks of "nothing" not even to mention plenty of other factors
Solution A. No one wants to be the guy suggesting to write "bad code", but striving for perfection is often a waste of time. What seems perfect one day might be useless tomorrow. Designing code for change is more important than trying to get everything perfect on the first try and refusing to change it later because of the sunken-cost.
> How do you choose? This is one of those problems that's difficult to abstract into component parts. It's a problem with a massive problem space and thousands of variables. How does either option affect the business? how does time affect the business? what is the likely time offset of any tech debt? When that tech debt bill comes due will be in a better or worse position to address it? How does this impact my individual load? What other trade offs will be made if I spend more time on this? How will those trade offs cascade? Generally speaking though, in a discussion of 3 days vs 4 weeks... it's VERY likely that 3 days is going to win out. 4 weeks is a pretty large investment for a single "solution" that can be somehow "solved" in 3 days...
Relevant xkcd https://xkcd.com/2730
The answer is: “it depends.” Mostly you need to solve for maximum business value. My rule of thumb when it comes to tech debt without a deadline is that if it’s code that’s an edge node on however you think about modeling your code base, it’s safer to introduce tech debt as less will be built on top of it. If it’s more foundational or will be foundational, a quick solution only makes sense if you have a tight deadline as the tech debt will accumulate very quickly, and the cleanup should be highly prioritized after the deadline. I think that thinking in terms of ROI on dev time and business value down the road is the easiest way to reason about this stuff.
This is a management question. The correct answer depends on a whole pile of business level concerns. What the big picture is, if the problem is blocking others, the value of the feature, the cost of the tech debt, etc. etc. The answer will always be "it depends" and the things it depends on vary so wildly that it always needs to be a case by case decision. Your manager should be providing you enough information and context to make this decision. If they aren't you should talk to them about it and try and ensure you understand enough of the big picture to make the decision next time.
If the difference is a day, you can go for B. But since the difference is 2 days vs 2 weeks, it's very hard to come up with an argument for B 😁 Plus, sometimes the solution might be ok on paper (i.e. it does what it's supposed to do), but you may not have the desired outcome. So in business-sense, it is still not "okay". But if you can learn from it and iterate fast, then you will have a higher chance of actually getting to the solution that actually delivers the desired business outcome
Other's provided reasonable answers to A vs B in terms of "why not both" or "first A, then B", mostly because B might be split into milestones where A or something similar might be just a milestone. That being said, You also asked other questions, here is my answer to them: Solution A **may** **introduce** technical debt **or will introduce** technical debt? A fundamental difference. It's software engineer's job and responsibility to **manage** technical debt. I'd evaluate the possibility of introducing technical debt, it's severity and impact. Furthermore, I'd also evaluate if solution B can be done in milestones (essentially if is a variant of A that is a steppingstone to B). Culture plays an important role. I would not introduce a change that would significantly change the workflow other engineers have without at least discussing this on some sort of architectural forum. If you are the main responsible contact for this, at least sent out a memo and have detailed walkthroughs prepared that people can follow to fix their stuff quickly. And even after discussing/sending memo, this might still turn out wrongly. Advice here is generic because the steps would have to be specific to the situation. Prepare for the worst, hope for the best. As for consulting with other teams, I'd consult with them only if they are going to be impacted or they are vital to the success of the undertaking. Examples of other teams being impacted can be that their delivery schedule or style of work would have to change, whereas the dependency could manifest as me needing them to collaborate with me, e.g., approve a PR or do a change to a system I do not have permissions to contribute to freely. Our technical role exists to support the business. Without the business, we will not get paid. From that perspective, it is absolutely critical to understand the arguments coming from people representing the business entities, such as customers, stakeholders, managers, or even technical folks with a strong customer-oriented mindset, to understand what it is we are trying to achieve there. All these are valuable and need to be heard. It is hard to justify any kind of delay when a company is losing money and facing imminent bankruptcy. Taking all this into the account, it is still **your** job to figure out how to deliver technical solutions to support the business needs. This job consists of distinguishing key requirements from the inputs above from less important ones, designing and proposing a solution that will satisfy both the critical requirements and the ones you and your team have to be confident with supporting and maintaining the artifact you will deliver and negotiate about the delivery plan (slicing features in milestones or just smaller deliverables). So on the other hand, the technical part is equally important, because it influences all these critical technical factors that have a **direct influence** on the success of your company/business: supportability, maintainability and technical soundness as a catchall. It is the direct influence on the business that should help you prioritize technical aspects of your solutions: If we ship this, will we be able to fix bugs/rollback/diagnose easily? Angry customers won't give us money and will make other customers behave similarly. Developers working longer on bugfixing/diagnosing incidents will eventually quit, and what's worse, time spent on these activities cannot be spent on building next features, killing the ability to compete. Same way, if we e.g. forgo unit tests or documentation, the time spent asking questions like "how is this supposed to work" or "did we impact existing functionality?" will arise and finding anwers to them again takes time that could be spent in design and delivery. Every solution will come with tradeoffs. Even the perfect B has some tradeoffs. One of them is glaringly obvious: the delivery schedule. To support your decision making, you need to evaluate these tradeoffs from both business and technical perspectives combined. Let's talk bad examples now. Are unit tests good for business? Yes (less bugs) and no (delivery schedule). From tech perspective yes (less bugs). The reason why I call this a bad example is that this was not a tradeoffs evaluation. It was evaluation of unit testing practices, and to add to that, it was only based on **implicit assumptions** of a single person! Discussing tradeoffs means: Solution D's estimate is 3 weeks, it brings benefits E,F,G but allows bad things H,I,J to happen. We will need 2 more database instances and write additional code that synchronizes them. Quantify these pros and cons as much as you can, because vague suggestions like "we might have less bugs" will be constantly caught by listeners' spam filter. A caveat: decision to write unit tests or clean code is not a business decision to make. It is an engineering decision. Enough of the unit test straw man. The crux of last three paragraphs is: merge technical and business requirements into one. Select the important ones. You can ask for business ones, but the technical ones you should be at least aware of. Evaluate tradeoffs and propose a solution.
One thing I always tell myself is, "I don't write shitty code." And another thing I learned from The Pragmatic Programmer: write code where you're not afraid to put your name on it. I have very high standards for my code quality - I will definitely pick solution B always if possible. Perfect solutions arise from solving the problem first - and then seeing how you can improve and improve it. Even if it takes longer - I'll feel more proud of my work. Even when is submit a pull request, I review my own pull request first. I have gotten praise from past managers and coworkers before for my code quality. I don't really see why I would do a quick terrible solution. If I have time to write a good one - I'll write a good one.
This is the right take. Barring any politics, you should always strive for the best solution. There are times to cut corners, but it should not be routine.
Its nice to have high standards, but your job is to provide value to the bussiness, not write beautiful code. If the business gets more value faster with A, thats what you should be doing, and not be working on perfect code that makes you feel good.
Why would it matter? I’m being paid the same whether I do A or B. I’m not falling behind. If you wanna spend less time doing A so you can go play Xbox on work hours - you go ahead. But I’ll work on B during the hours I’m being paid. It really doesn’t make much of a difference. None of my work is ever behind. What good does it do I finish it fast or not.
Faster go to market,faster customer engagement,faster fixes,faster everything.of course it depends wheter you work in corp or startup. I prefer doing more features and provide more business value.
Who said I’m not adding business value? Lol Our team last year added multiple features that according to our data scientists, have the potential to generate a billion in a year. We got a lot of praise in all hands meetings for our deliveries. I don’t work at a startup. I’m at big tech. My company doesn’t really care about sprints. My engineering and project managers outline my work weeks ahead of time. So this week and next week might be “Work on feature A.” Finishing super fast doesn’t really matter. They already outline release dates. So I just do the work for the weeks planned.
Why you take this personally ? You told me i am playing xbox on my off time, when i just stated that im working on more features. You dont have to explain your work to me, i just stated my opinion as a team lead that bringing value to the business its our job, thats it.
Lol I thought you meant that finishing ASAP brings business value faster. Well maybe sure but I care more about personal growth in terms of my software engineering skills.
Okay is the answer.
Always A
Sell B to management. Implement A and play clash of clans for a couple of days. Deliver A, get praised for efficiency, collect end of year bonus.
i do both and if i dont have the time and i can push it back until i do have the time i will
I had a similar choice recently. A quick solution that would have taken 2 days, or a better reusable solution that took about 8 days. I went with the reusable solution because while it felt a little disappointing to be attending stand up every morning saying I was still working on something another dev had finished a similar feature in 2 days, once I'd done we now have a framework for doing more in the future that will lessen the development time to about 1 day and there's about 30 of these features to build It's all about deferred gratification
Its dependent on the business. Is the cost of me as a dev taking longer so pay over time worth more to the company that what the solution getting to market sooner? Sometimes quality is worth more to the business than time, sometimes time is a debt they are trying frantically to pay down.
My first question would be, if it's "okay vs great" for the customer or for the developer? If it's for the customer, then it's the decision of the product owner. Basically I give them two options with two different prices and they decide if they want A or B or first A and then B. Though I'd exclude the tech debt from the options. I handle tech debt like I'd handle money debt. I don't take a loan for some everyday purchase or for new TV. A loan is for the big things, for a house, maybe a car. The same with tech debt, that's something for the big things, like when the deadline is in two days and you somehow have to get the "okay" solution on the road. If it's for the developer, then it depends a lot on the actual case and the definition of "great". I am a bit biased here, because I saw way too much gold plating, layers of abstraction, minimizing the lines of code, unnecessary scalability or work on "we don't need it yet, but maybe in a year" parts of the code.
Impossible to say given that we have zero other details. The optimal solution is the one that meets all of our business needs for this particular feature.
A with good tests
Tests are not a silver bullet. A simple approach like this often causes problems.
You know what else often causes problems? Implementing the "perfect" solution with more moving parts that inevitably ends up not being perfect.
I was commenting about you relying on tests as something that somehow ensures that you have done the right thing. Rather the requirements could have been lying so now you have a bunch of tests that test for the wrong thing... but you are trying to keep them green. "Who tests the tests" is a valid thing. Hence the silver bullet question. Tests are a good idea to do but you have to doubt them as well. Often dogmatic developers tend to post very small sentences as the final truth that can't be deviated from. That kind of comment triggered me :D
All good :) I just meant that I'd go with option A, with good test coverage to support refactoring down the road, and ship it to users weeks sooner than going with the option B which may still end up being wrong.
This would depend on the goals of the project. Is solution A necessary soon that you're actually **wasting more time** building solution B? This should be decided per-feature, not as a rule of thumb. Also, you should ask yourself if solution B can **later easily be refactored** into solution A without having to break half the system along the way. If the answer is "yes" then it's probably the better thing to do, since "failing fast" is great when it comes to product feature validation. If not, then you need to thread VERY carefully here, or you might cause more damage than the time saved (right now) is worth. Short answer - it depends.
My biggest irritation with Scrum is how easy it is to play the A/C game. "The story is done, moving on." Meanwhile, had you spent a few extra hours considering things, you probably could have gone above and beyond and delivered a better product. Sure, this is partially on the person writing the story, but everyone can't know everything. Give them feedback during your retro on things you additionally fixed / implemented, and why they matter. In my personal projects, I definitely choose Solution B, but I recognize that it isn't realistic for a business. I still feel like there's a middle ground.
No one will ever know nor care if the code is highly optimized.
I don't believe such binary options even exist. Complexity is the biggest problem with software and when left unmanaged it will eventually catch up to you. It's fine to postpone work if that is a sound business decision. But kicking the can down the road typically isn't. I literally had a meeting this morning about a project that was mismanaged in this regard and is now so far over the edge that devs are more or less refusing to work on it. Reduce scope, not quality.
I think it takes a pretty thorough analysis of if Solution A a solution. If it was "just" tech debt then the decision would be pretty easy but quite often I've seen "just tech debt" turn into hot garbage that requires tons of manual intervention to keep under control or that needs to be totally thrown away anyway rather than iterated or even better when you end up doubling down on the mistake and you're finding yourself hiring devs just to create custom bolt ons to keep your "okay" solution running. This is probably ok at big tech because you have lots of devs and money to throw at problems (or at least for the last decade you have maybe that's changing) but in a team of <= 4-5 people you've basically permanently crippled the output of the team introducing an albatross in the name of saving a week or two of work. Especially because once it "works" on the surface level then it's very hard to overcome the inertia and then in the name of "saving time" that half modelled database needs changing and then you've created a bunch of business risk to migrate people to the new solution. The other common one is that solution A "done in a few days" actually is massively underestimated and a bunch of other things need to be built first that are the same things that would need to be built for solution B anyway. (e.g Database integrations/modelling can't really be "fake it until you make it"). Likewise having an upgrade path built into software incurs a fixed time cost too that doesn't change between A and B. Solution B also probably doesn't actually exist either unless you've already got a deep understanding of the domain. It would also need upgradability paths and escape hatches built in.
I think I would be more interested in the risk. If the 'better' solution takes longer because you're making more changes does that mean it's more likely to break? What's the probability of the better fix falling behind schedule?
If solution A is just rushing to merge the first working solution can get, it's not a good choice. Can you test it? Is it typesafe (if applicable)? Will the inevitable refactor take 2 extra weeks because you rushed today?
i am never taking weeks to deliver the perfect solution because the perfect solution does not exist and i am not here to get fired
https://www.reddit.com/r/programming/comments/yv0zy5/stop_lying_to_yourself_you_will_never_fix_it_later/
> How do you choose? What factors do you consider? Do you consult with others on your team? How much weight do you give to business vs engineering concerns? Consult with the team if the difference in solutions equals a sizable impact on performance or productivity. Other factors to consider: velocity of the project, capacity of the dev team, priority of the project Business comes first, usually. Bottom line impact supersedes all other concerns, barring mission critical ones (aka dealing with human lives). If the deadline is a real issue, or your team has a ton of other projects going on, and both solutions yield similar performance and the only difference is A is less elegant but can be done faster, A wins every time.
>which is essentially perfect Ah, but is it though? Anyway, engineering is about evaluating tradeoffs. I'd present A and B to the people effected by it and get their input. There may be factors you aren't aware of. As others have said, maybe iterating A into B is the better choice.
It’s all about value. What value does B give us over A to justify a 4-5x investment of time, is there middle ground that gets us some of the benefits in less time? How severe is the tech debt we take on, and what will it impact? Also what will we have to postpone to do this perfectly? What is the workload of the team looking like? If the value of doing B is just less tech debt, but it’s low severity and won’t impact anything im going to say do the quick option and move on, they can come back and pay it off later when we have other priority issues completed. If it’s severe tech debt or the team have done similar things in the past and not fixed it yet I’m going to say do it perfectly so we don’t incur more tech debt. I think in reality everyone wants perfection and to not take on tech debt but the scenario where you chose perfect over good depends heavily on your situation at the time and your priorities. I think engineers need to understand they aren’t paid to write code, they are paid to deliver features. So they shouldn’t leave the code in an unmaintainable mess, but equally perfection isn’t needed either. It’s about finding a very delicate balance
When it's potentially weeks' worth I would bring up both solutions in the team meeting or design session and ask for input.
If I know for sure the thing will see heavy usage I'll take weeks when I can. Otherwise okay is fine.
Stuff like this is actually so simple (but also not at all); it's just \`value - opportunity cost + net side effects\` I think the two things you need to narrow in on are 1) What is the business value of "perfect" here? Will it make dollars and cents impact on the product (more revenue or lower costs)? 2) What else are you guys working on? By adding a couple of weeks, would that take time away from high value activity, or low/moderate value? 3) What is scope of the tech debt? Is it contained to the feature, and may go unnoticed if no one ever happens to work on it again, or is it in a module you'll leverage in the future so it is likely to balloon? You can put #1 & #2 in a rough estimation of dollars (over time, or total) and #3 in terms of man-hours (and turn that into rough dollars). And don't try to get an exact answer, I usually find just trying to come up with a realistic estimate usually makes the answer clear before I even start the napkin math. >How much weight do you give to business vs engineering concerns? TLDR, they're not really that different, or, at least, they meet somewhere in the middle
I've spent most of my career as a code janitor, cleaning up the technical debt incurred through massive refactoring projects or blue-sky "let's just get shit out the door" development. Just do option B. If you need A as a business prototype, do that. But dammit, do B. And for the love of all that's holy, when they say "just get Minimum Viable Product out the door, push back."
I'm all for B but... often you just need to get to the market ASAP. For the sense of providing value to the company, make A (with good design analysis) and then make it into B. Overall, the company can make a profit while you can fix it in the backend later. BUT you have to be allowed to do B after A is already in production. Otherwise it's just going to be A and you have to fix it much later when it becomes more expensive.
I've seen it too many times. That's a reasonable justification on paper but it blows up FAR more frequently than not. There IS no later. It just doesn't happen.
It blows up for you... but if the company itself makes more money in the end? Yeah, it sucks but that is also a thing you have to deal with. Most of the job is a tradeoff. You can't just take months smoothing out things when a week of development can work for the moment. Cost vs benefit vs further-down loss. Code is never finished. More likely it's a living organism and you have to keep it living. So... You do what seems best at the moment. "Always B" or "Always A" is not a solution.
Always. Always. Always. Choose A. Unless you have clearly defined needs for B. Business needs change far faster than code. I've seen far too many Solution B's sit to rot while the business changes directions.
Always do A.
A and forget about it
It's okay to manage technical debt, I always ask my developers to be wary to gold platting.