As a dev i've always known my hunch when it comes to compromises. Never let the business team ruin your experience building cool rock-solid code. I'd rather resign than to compromise anymore. I know there should be a sweet spot between "perfect" and "working". Even a junior can pull-off a "working" app. But when it starts to scale, all those hasty bad decisions will bite your ass. Never skip planning, plan as long as you need. Nowadays i start coding only after i have 100% visibility into what i'm building: diagrams, dependency graph, schemas, types and data structures, documentation, user flows, everything. As the say goes: if i have 24h to chop a tree, i'd sharpen my axe 23h. And we haven't yet taken into account infrastructure, devops, ci/cd, security, releases, logging, and all sorts of tooling. I need around 2 months just for initial planning, setting everything up and laying out the codebase structure.
I apologize if this sounds harsh, but I can't see the /s anywhere and I want to clarify for others.
This post outlines how to destroy a new (or any) business.
There will never be anything approaching 100% clarity between different people talking about a thing that doesn't yet exist.
We all have to see it and feel it in order to truly understand it.
This experience almost always leads to creating new, better ideas, discarding old ideas and digging deeper on others.
That's all before we even leave the building and learn from customers.
I shudder to imagine trying to get a start up off the ground and needing to wait 3-6 months for the first commits only to then have to argue about change orders with my eng team.
I would say a related point to that is: don't skimp on unit and integration tests. It's easy to rush code out but tests will force you to think through it and give you a way to quickly test if a change is a breaking one.
But as a counter point, early in a product lifecycle you don't even know if the product you are building is what you are going to find a market fit for. So spending a lot of time getting the tech perfect is sometimes a waste. It's a constant calculation of balancing the risk of not scaling with the risk of taking so long you never get to the point where you can scale.
> Tests are for teams of contractors that don't know how the product works.
The opposite. Tests are for people who know exactly how the product works. It's very hard to write good tests if you don't understand the product (or at least your piece).
I really hope you are being sarcastic. Tests when done properly speed up development and make your product more robust and resistant to breaking changes.
For a proof of concept that will never see production, sure, by all means don't write tests. But in my 15+ years in CTO and Principal role at smaller companies, the most expensive projects with the most downtime are always the ones without tests.
Tests make software cheaper not more expensive. And the ROI isn't even that long... all it takes is for two to three iteration / release cycles.
In my case, I haven't really considered integrations tests, as I didn't have the time. Only the bare minimum unit tests "it('should render or shouldnt fail')"
if a component is core to your strategy or product then by all means make sure it's rock solid.
but if you're iterating on your product and you don't know which feature is going to be used then don't waste time perfecting it.
we put together in days products that we shutdown in 3 months, we would have never been able to move at such speed if we took our time plan, design, develop ...
and business people do come with a lot of things that go nowhere (depending on your company sales culture of course and product maturity)
Good luck with that trying to find PMF and first 100 customers. Later stage, I get it sort of. Seed and A series you will kill your company by being too slow. Waterfall does not work for this.
Thanks for sharing your thoughts here. I think it's useful for us to get a glimpse into your thought process and start a discussion.
Though I empathize with the overall desire, you sound inexperienced to me, as in, you might have had some failures that you attributed to lack of planning or business decisions, etc, but you haven't learnt from successes, because some of the stuff you're saying is just extreme counterproductive wishful thinking to the point where it sounds like trolling.
For example, 'building cool rock-solid code' is typically not a business goal or at best, a nice to have. Developers are hired to solve a business problem. If the code doesn't solve the problem, you're wasting precious resources. 'cool code' is a personal choice.
Compromising is essentially a trade-off like any other, and it requires careful deliberation in every context. Your opting to not compromise by default means that you're introducing friction in the team, in the business relationship and potentially affecting the life of the business, not to mention that it's a 'us vs them' mentality when you're supposed to be part of a team to deliver a product together.
Your reasoning about hasty decisions biting you is also backwards. Notice how you're just assuming that a product will start getting enough users to need to scale. Guess what: like most products, the product you worked on was actually not that great, didn't have a good product-market fit and if you hadn't spent all that time polishing and planning the cool non-junior code, you might have saved everyone months of time.
Also you go from 'never skip planning' to 'take as long as you need'. Those are 2 extreme approaches. It turns out that a little planning goes a long way. You can come back and iterate on the plan. No plan is going to be perfect from the start, because you don't have all of the information available to you when you start a project. As you develop a project, you get more information on hidden requirements, user expectations, non-functional requirements and various other metrics that you couldn't have thought about ahead of time.
What you are describing is the waterfall approach to software development and the only way it doesn't fail is if the domain and the product are very well understood (e.g. "build a grep clone in Rust"), but most products aren't well understood ahead of time, only in retrospect, so it's a constant back-and-forth between acquiring new understandings about the product and applying them in practice by changing what's already there. It requires your code to be flexible, not 'cool' or 'rock solid'.
Consequently, you will never get 100% visibility into what you are building. If you find yourself thinking "gee I know exactly what we are building" you are setting yourself up for disappointment when 'the business people' pull the rug under all your diagrams and schemas and types that you spent months designing instead of getting a usable POC out the door asap.
Honestly, it's just a phase you're going through. Once you get burned by your current approach a few times, you'll internalize the need to avoid either extremes and you'll start looking for that middle ground with each project. I know it because I went through the same phase in my career. Good luck!
You have it completely reversed, a rock solid codebase is much more important in an agile environment than a waterfall one. In waterfall you just need to tick the feature boxes. In Agile you not only need code that readily accepts changes, but you need to provide visibility to the business side about the state of your technology so they know not only the opportunities but also the costs of the problem.
The only reason why this becomes a phase that burns developers out is that writing high quality software is hard, under-appreciated and needs to be painstakingly learned by experience and guidance by experienced mentors. But most projects in the industry are complete shitheaps where the seniors need to spend all their time fighting fires instead of teaching the craft to juniors. No wonder developers get burned out.
Well, I don't disagree that a rock solid codebase is important in either environment. It's the cost of change that is usually at stake, like you mentioned, and that's why I'm arguing that flexibility is more important.than code quality in an agile environment, particularly at the beginning of a project when there are the most unknowns.
You're hitting the nail on the head about burning out though. I suppose it's just the way the cookie crumbles.
> Thanks for sharing your thoughts here. I think it's useful for us to get a glimpse into your thought process and start a discussion.
Thanks for your awesome reply! Means a lot to me! Let me dive along! To make this discussion more interesting from the start, I'm going to say that we managed to raise $2M with an MVP written in 4 months, and now I have to rewrite everything because the business team pivoted 180 degrees. Bear with me a little.
> Though I empathize with the overall desire, you sound inexperienced to me, as in, you might have had some failures that you attributed to lack of planning or business decisions, etc, but you haven't learnt from successes, because some of the stuff you're saying is just extreme counterproductive wishful thinking to the point where it sounds like trolling.
The only failure I feel is that I haven't really managed to employ the right people for the right job. This forces me to take care of everything - really, like I have to refactor Typescript interfaces or CSS for other people, which are trivial things but time consuming. On one hand, I have to move fast and deliver features as a team, but on the other hand, I have to teach people how to properly do their job.
> For example, 'building cool rock-solid code' is typically not a business goal or at best, a nice to have. Developers are hired to solve a business problem. If the code doesn't solve the problem, you're wasting precious resources. 'cool code' is a personal choice.
The expression 'building cool rock-solid code' might've been just me venting my frustration - it's not that hard to do a good job it if you know what you're doing. But you're 100% right: I'm wasting resources if I don't implement the business needs in a timely manner. I actually managed to pull that off before raising the money.
But I'm also aware that difficult problems have more than ordinary solutions. I took care of our infra, from Proxmox, docker, Google Cloud, Jira, Confluence, Cloudflare, to Slack, emails, Jira, Confluence and others. The business team just says: "we could've employed anyone to do that".... really ....
> Compromising is essentially a trade-off like any other, and it requires careful deliberation in every context. Your opting to not compromise by default means that you're introducing friction in the team, in the business relationship and potentially affecting the life of the business, not to mention that it's a 'us vs them' mentality when you're supposed to be part of a team to deliver a product together.
Actually you're right and this is the reality. IMO, I see the grand scheme of things, where I know what "should" be done, so we could attain 100% autonomy and be able to scale without coding anymore, whereas the business team needs some features NOW, forcing me to do shortcuts. This is why I'm pushing to build a roadmap, but it's obvious we cannot do it right now.
> Your reasoning about hasty decisions biting you is also backwards. Notice how you're just assuming that a product will start getting enough users to need to scale. Guess what: like most products, the product you worked on was actually not that great, didn't have a good product-market fit and if you hadn't spent all that time polishing and planning the cool non-junior code, you might have saved everyone months of time.
We have 10k users, we have the market fit, we have the funding. The only problem is that I built everything for a specific business case, and now I have to abstract it to support the previous business case, plus new others, which are completely different. It's like building a new product from scratch. And my pain is that we could've thought about it from the start - this would've allowed me to abstract some of business logic.
> Also you go from 'never skip planning' to 'take as long as you need'. Those are 2 extreme approaches. It turns out that a little planning goes a long way. You can come back and iterate on the plan. No plan is going to be perfect from the start, because you don't have all of the information available to you when you start a project. As you develop a project, you get more information on hidden requirements, user expectations, non-functional requirements and various other metrics that you couldn't have thought about ahead of time.
Exactly, no plan is going to be perfect, and we're constantly iterating over it, but we didn't allowed ourselves to start this damn plan from the beginning. We thought: "let's do it, see what happens. Wow, it worked! Let's do even more now, and be backwards compatible"
> What you are describing is the waterfall approach to software development and the only way it doesn't fail is if the domain and the product are very well understood (e.g. "build a grep clone in Rust"), but most products aren't well understood ahead of time, only in retrospect, so it's a constant back-and-forth between acquiring new understandings about the product and applying them in practice by changing what's already there. It requires your code to be flexible, not 'cool' or 'rock solid'.
EXACTLY! We had poor product and domain knowledge - basically we built our way without having a good sense for them. The code is flexible enough: monorepo with apps and libs sliced and combined in separate packages, while trying to follow 12-factor-app methodology as much as I could.
> Consequently, you will never get 100% visibility into what you are building. If you find yourself thinking "gee I know exactly what we are building" you are setting yourself up for disappointment when 'the business people' pull the rug under all your diagrams and schemas and types that you spent months designing instead of getting a usable POC out the door asap.
This is where the friction comes inside the team. I want to plan as best I can do it, and then just execute. Talking about my experience, I was employed in a German project where people actually took their time to plan thoroughly, at a point where they knew exactly what people they needed and almost the exact buget for the whole thing. And it was a joy to code and do your thing. In retrospective, looking at this German team, they really knew their tools and craft.
> Honestly, it's just a phase you're going through. Once you get burned by your current approach a few times, you'll internalize the need to avoid either extremes and you'll start looking for that middle ground with each project. I know it because I went through the same phase in my career. Good luck!
I've been using solutions like Supabase, Hasura, n8n, Prisma, just to move things faster. IMO, it all boils down to understanding the product and domain. Then the table schemas, data structures, interfaces, services, etc, will start fitting into place. In my case, they still do, partially, but I could've done a better job at abstracting them from the first place, rather than patching or rewriting shit at this point. I'm lazy.
My takeaway, even it might sound childish or wishful thinking, is this:
1. I won't start a startup with non-techincal founders anymore
2. I won't touch a single line of code if I don't understand 100% the product and the domains
3. I will strive to employ only the right people for the job and I will document everything from the start, so the onboarding curve would be low
4. I will enforce best practices, standards and internal protocols when it comes to writing, testing and deploying code.
5. I don't want to think when I read code; a quick glimpse is what it takes: looks good, passes tests => OK
6. I want to be able to delegate as much as I can, without fearing that quality might suffer
7. I should follow my guts and speak louder when the business team wants the Pyramid of Giza - at a point looks like a challenge that I accept, but then it translates into lost nights for myself.
I might be biased, I know I'm not that experienced yet, I know there's no such thing as a perfect world, but I can strive to achieve that. Maybe I'm just venting - nonetheless, it's still possible to build a product without having a gun pointing at your head.
