4 ms·

Ask HN: Build dirty and clean up afterwards?

Hi crowd, throw-away account for obvious reason. I work at a SaaS company, that has a product consisting of a web backend and an app frontend. I work there for 2 years, and have 13 years of experience in the industry, working as a software developer. I have worked on products and projects alike. The company I'm working for is now a decade old, and started with a dozen people. It was VC funded, and had a pretty strong incentive to get to the market real quick. This now shows, as the code for the backend and frontend is subpar, with questionable architectural decisions in the past. However, architecturally, the app frontend is in better condition than the backend. The market (=our customers) more and more demand not only a web backend, but also a web frontend. While a team currently reworks the backend, another team is formed which should build up a web frontend. There are two ideas: One is to build the web frontend as quick as possible, so that we can deliver a much wanted web frontend as fast as possible. We would copy the architectural, not-optimal idea and UX from the current app and put that into the web frontend. The idea is than, for the 12 - 18 months after release, to rework the web frontend architecturally. This would allow almost no room for feature development. This is also the road the web backend is currently taking, where I wasn't involved in the decision making process. The other idea is to put the invest up-front, re-thinking existing ideas, and build the web frontend without repeating mistakes from the past. This would allow to focus on features after everything is done. It will however mean that the release of the web frontend will happen later. While I cannot go into much more detail without giving away my identity, I'd rather prefer the latter. My argument against the first way is that, we as a company, may not be able to withstand the pressure to deliver features, as our comptetitors now already can do things we cannot do. Also, with the rise of AI-assistance, we will sooner or later need to integrate certain features into our frontend. In the past, everytime a "we will do it better afterwards" was announced, the phase of "doing it better" simply didn't happen. I'm burned on this one. The argument against the second way is, that we, as a dev team, proved in past features that we cannot focus on the scope and might blow up the whole thing, if we want to get the architecture and UX right in the first step. It was basically questioned that we have the competence to build what was asked. What do you folks think?

austin-cheney 3y ago
It sounds like you don't know what you are doing. Don't be shocked, not knowing what you are doing and praying that a tech stack will do it for you is the norm... by far. It can be done correctly and faster and cost less than alternative approaches. Here is how you do that: 1. Start with the end in mind. Know what you want from a product perspective and write that down. Most places are not capable of getting this correct. The more precisely you know what you want the less it will cost to build. 2. Know the platform. Most people have absolutely no idea how the front end works and are completely reliant upon some tool chain. A tool will allow setting up an application somewhat quickly in the absence of a plan, but again the costs will spiral up as you build it. This is why software is hard to estimate. If you don't know what you are doing then hire a temporary consultant to drive this bus. A framework or build tool is the most incorrect answer. 3. Automation. Supposedly software is written by software people and yet rarely are things well automated. You need centralized user-facing product documentation, test automation, code validation, accessibility, and such written in parallel to the actual product. If you know what you are doing this costs far less than you think. If you bolt it on later it will be extremely expensive and horribly incomplete. 4. Always remain focused on the product, the end state for the user. Most shops get this wrong too and instead think about their tools, code vanity, popular trends for hiring, and other irrelevant distractions. Focus. I hope this goes well for you.
- throwaway_12584 3y ago
  Thank you for your input! You are correct, the tech-stack for the front end will be completely new to us. In fact, we devs also should unify the app and web, and put them on the same tech stack. My biggest concern is that product department and dev department will drift apart and simply loose focus on what our product is and what our customers need. Which would be a shame, because our customers love what we are building. It helps them a lot.
  - austin-cheney 3y ago
    That is a super valid concern. The solution for that is a product owner position. The product owner should have these qualities: * Strong written communication skills like a QA but also with a mindset for prioritizing tasks with respect for strategy and expense. * A technical background deep enough to understand product quality. Product quality comes from measurements of things like execution speed, regression trending, accessibility, A/B testing, service related expenses, and so on. * A risk taker. An ideal product owner is willing to accept liability for product failures and simultaneously push back on bad ideas. A bad idea is something that deviates from product goals, a budget destroying idea, or something that fails A/B testing.
Archelaos 3y ago
One aspect in favour of the first solution (making the transition as fast as possible, without re-architecture first) is its greater flexibility. You probably can break down the re-architecture requirement into several parts afterwards. Ideally, you can treat each of these parts as an individual feature having its own priority and put them into the same basket as the other request for new features. You do not then need a master-plan for everything in advance. Instead, you only need to identify the most important feature out of this basket to work on first. After implementing it, the feature basket and its evaluation might have changed, so you can adjust your path in the light of new insights. In contrast, the master-plan approach is probably somewhat faster, if the requirements do not change much during its implementation, because you might be able to cut corners. Since you seem to be rather uncomfortable to choose between the two options, I would take this as a strong indication that you should not miss out on the flexibility provided by the first approach.
- throwaway_12584 3y ago
  So you would rank the flexibility aspect higher, I see. My past experience shows me that the "we need to get the architecture right here“ will often be down-prioritized, as these efforts are not visible to the end-user. That’s something I fear might happen again, because no one with their right mind will say "No." to a customer, waving with a pile of money, that needs feature "XYZ" to close the deal. While the decision itself is not mine to make, I‘m involved in the finding process. And I'm currently leaning towards the "let’s do as much as feasible up-front" group.

austin-cheney 3y ago

It sounds like you don't know what you are doing. Don't be shocked, not knowing what you are doing and praying that a tech stack will do it for you is the norm... by far. It can be done correctly and faster and cost less than alternative approaches. Here is how you do that: 1. Start with the end in mind. Know what you want from a product perspective and write that down. Most places are not capable of getting this correct. The more precisely you know what you want the less it will cost to build. 2. Know the platform. Most people have absolutely no idea how the front end works and are completely reliant upon some tool chain. A tool will allow setting up an application somewhat quickly in the absence of a plan, but again the costs will spiral up as you build it. This is why software is hard to estimate. If you don't know what you are doing then hire a temporary consultant to drive this bus. A framework or build tool is the most incorrect answer. 3. Automation. Supposedly software is written by software people and yet rarely are things well automated. You need centralized user-facing product documentation, test automation, code validation, accessibility, and such written in parallel to the actual product. If you know what you are doing this costs far less than you think. If you bolt it on later it will be extremely expensive and horribly incomplete. 4. Always remain focused on the product, the end state for the user. Most shops get this wrong too and instead think about their tools, code vanity, popular trends for hiring, and other irrelevant distractions. Focus. I hope this goes well for you.

throwaway_12584 3y ago
Thank you for your input! You are correct, the tech-stack for the front end will be completely new to us. In fact, we devs also should unify the app and web, and put them on the same tech stack. My biggest concern is that product department and dev department will drift apart and simply loose focus on what our product is and what our customers need. Which would be a shame, because our customers love what we are building. It helps them a lot.
- austin-cheney 3y ago
  That is a super valid concern. The solution for that is a product owner position. The product owner should have these qualities: * Strong written communication skills like a QA but also with a mindset for prioritizing tasks with respect for strategy and expense. * A technical background deep enough to understand product quality. Product quality comes from measurements of things like execution speed, regression trending, accessibility, A/B testing, service related expenses, and so on. * A risk taker. An ideal product owner is willing to accept liability for product failures and simultaneously push back on bad ideas. A bad idea is something that deviates from product goals, a budget destroying idea, or something that fails A/B testing.

Archelaos 3y ago

One aspect in favour of the first solution (making the transition as fast as possible, without re-architecture first) is its greater flexibility. You probably can break down the re-architecture requirement into several parts afterwards. Ideally, you can treat each of these parts as an individual feature having its own priority and put them into the same basket as the other request for new features. You do not then need a master-plan for everything in advance. Instead, you only need to identify the most important feature out of this basket to work on first. After implementing it, the feature basket and its evaluation might have changed, so you can adjust your path in the light of new insights. In contrast, the master-plan approach is probably somewhat faster, if the requirements do not change much during its implementation, because you might be able to cut corners. Since you seem to be rather uncomfortable to choose between the two options, I would take this as a strong indication that you should not miss out on the flexibility provided by the first approach.

throwaway_12584 3y ago
So you would rank the flexibility aspect higher, I see. My past experience shows me that the "we need to get the architecture right here“ will often be down-prioritized, as these efforts are not visible to the end-user. That’s something I fear might happen again, because no one with their right mind will say "No." to a customer, waving with a pile of money, that needs feature "XYZ" to close the deal. While the decision itself is not mine to make, I‘m involved in the finding process. And I'm currently leaning towards the "let’s do as much as feasible up-front" group.