5 ms·

I not totally agree with this. Architecture is really important because it can make new feature less expensive in term of development. If you judge a work only

I not totally agree with this. Architecture is really important because it can make new feature less expensive in term of development. If you judge a work only in terms of final product UX, you miss this point.

darkhorse13 5y ago
I don't disagree with you, but I've also seen working products get thrown away because of "bad architecture", only to waste tons of money and time. The worst part: the users literally never cared either way, they just wanted the product to solve their problem.
- ipaddr 5y ago
  They care later when new features cannot be added, changes are delayed. A bad architecture is sometimes what you need but it will only take you so far. Architecture is important but not as important as getting the data-model right. We can refactor out bad architecture but a bad datamodel will have missing or inaccessible data since it was created and you cannot get that back.
  - darkhorse13 5y ago
    Not if your company goes bankrupt trying to prematurely upgrade the architecture, which is usually a huge undertaking. I think that's the entire point of the article, the guy who wrote it is clearly using a startup POV.
    - xupybd 5y ago
      It makes sense to build a cheap and dirty system to start. Especially if you want to build it then inject loads of cash when it takes off. But it is still a cheap and dirty system. Too many people do build like this initially but are not willing to pay to fix the mess when it starts to get hard to add new features.
  - arcbyte 5y ago
    The data model serves the architecture. The architecture serves the use cases. Data models are a dime a dozen and are throwaway.
    - ipaddr 5y ago
      Your data model is the heart of your business. Let's say you have a genetic product and require the user to upload their dna results and certain datapoints are taken and stored. If you decide later you want different datapoints and have not saved the original uploaded file you can't offer past customers new products. Your architecture can change.
      - arcbyte 5y ago
        Youre proving my point. Saving the whole file or not is an architectural decision involving cost tradeoffs, technology capabilities, and business strategy. Which data points you put in your OLTP is the data model and, as you just painted an example of, throwaway when the use cases change. Later you'll want different data points or different relations. And then you'll evolve your data model yo serve that. If you did your architecture right, it will change much less than the data in your databases.
- TheCoelacanth 5y ago
  A rewrite is always the wrong way to deal with a bad architecture. Evolve the architecture in place.
noway421 5y ago
Product-first engineers don't avoid architecture. They tend to know when you can skim on building it, or when the common development tools already provide enough of it. Sometimes, it's as simple as "frontend, backend, and a way to deploy it". Not to mention so many developer tooling products out there already decide on the architecture for you. Use anything firebase for example, and you'll be pretty railed in around the way your system is architected.
- josephg 5y ago
  Sure; well rounded engineers care about architecture as well. But in the same way some “code first” programmers are myopic and only really care about the code, plenty of product first engineers only really care how the product looks. I’ve met and worked with plenty of people who don’t have the skill to be creative with architecture, or don’t know how to structure the code to avoid certain bugs showing up over and over again. Or have no idea how to make their code run fast. - So their software becomes a beautiful, laggy mess. One “product first” engineer I worked with years ago made a database indexing system, syncing our data into elasticsearch so we could add text search to our product. For about 6 months after the feature launched we kept running into indexing bugs - where data was missing from the index and things like that. I (naturally code first) ended up helping rearchitect it. After we relaunched the feature we never had another indexing data bug as long as I was at the company. Sometimes it’s faster to take more time to do it right rather than do it wrong and spend your life playing whackamole with bugs. It all depends on your context. (Is this a MVP to throw away? Or are you working on code that will probably still be around in a few years?). The best engineers know how to adapt their own personal process to the needs of the project. Sometimes that means quick and dirty. Sometimes it means thinking it through and building it to last.
  - noway421 5y ago
    We're arguing about semantics. What you define as "well rounded" I define as "product-first". What you define as "product-first" I would define as "inexperienced".
    - 5y ago

darkhorse13 5y ago

I don't disagree with you, but I've also seen working products get thrown away because of "bad architecture", only to waste tons of money and time. The worst part: the users literally never cared either way, they just wanted the product to solve their problem.

ipaddr 5y ago
They care later when new features cannot be added, changes are delayed. A bad architecture is sometimes what you need but it will only take you so far. Architecture is important but not as important as getting the data-model right. We can refactor out bad architecture but a bad datamodel will have missing or inaccessible data since it was created and you cannot get that back.
- darkhorse13 5y ago
  Not if your company goes bankrupt trying to prematurely upgrade the architecture, which is usually a huge undertaking. I think that's the entire point of the article, the guy who wrote it is clearly using a startup POV.
  - xupybd 5y ago
    It makes sense to build a cheap and dirty system to start. Especially if you want to build it then inject loads of cash when it takes off. But it is still a cheap and dirty system. Too many people do build like this initially but are not willing to pay to fix the mess when it starts to get hard to add new features.
- arcbyte 5y ago
  The data model serves the architecture. The architecture serves the use cases. Data models are a dime a dozen and are throwaway.
  - ipaddr 5y ago
    Your data model is the heart of your business. Let's say you have a genetic product and require the user to upload their dna results and certain datapoints are taken and stored. If you decide later you want different datapoints and have not saved the original uploaded file you can't offer past customers new products. Your architecture can change.
    - arcbyte 5y ago
      Youre proving my point. Saving the whole file or not is an architectural decision involving cost tradeoffs, technology capabilities, and business strategy. Which data points you put in your OLTP is the data model and, as you just painted an example of, throwaway when the use cases change. Later you'll want different data points or different relations. And then you'll evolve your data model yo serve that. If you did your architecture right, it will change much less than the data in your databases.
TheCoelacanth 5y ago
A rewrite is always the wrong way to deal with a bad architecture. Evolve the architecture in place.

noway421 5y ago

Product-first engineers don't avoid architecture. They tend to know when you can skim on building it, or when the common development tools already provide enough of it. Sometimes, it's as simple as "frontend, backend, and a way to deploy it". Not to mention so many developer tooling products out there already decide on the architecture for you. Use anything firebase for example, and you'll be pretty railed in around the way your system is architected.

josephg 5y ago
Sure; well rounded engineers care about architecture as well. But in the same way some “code first” programmers are myopic and only really care about the code, plenty of product first engineers only really care how the product looks. I’ve met and worked with plenty of people who don’t have the skill to be creative with architecture, or don’t know how to structure the code to avoid certain bugs showing up over and over again. Or have no idea how to make their code run fast. - So their software becomes a beautiful, laggy mess. One “product first” engineer I worked with years ago made a database indexing system, syncing our data into elasticsearch so we could add text search to our product. For about 6 months after the feature launched we kept running into indexing bugs - where data was missing from the index and things like that. I (naturally code first) ended up helping rearchitect it. After we relaunched the feature we never had another indexing data bug as long as I was at the company. Sometimes it’s faster to take more time to do it right rather than do it wrong and spend your life playing whackamole with bugs. It all depends on your context. (Is this a MVP to throw away? Or are you working on code that will probably still be around in a few years?). The best engineers know how to adapt their own personal process to the needs of the project. Sometimes that means quick and dirty. Sometimes it means thinking it through and building it to last.
- noway421 5y ago
  We're arguing about semantics. What you define as "well rounded" I define as "product-first". What you define as "product-first" I would define as "inexperienced".
  - 5y ago