5 ms·

>> There must be a middle ground where developers can focus on the core business logic that yields the most value without incurring technical debt and making th

>> There must be a middle ground where developers can focus on the core business logic that yields the most value without incurring technical debt and making the development process a nightmare. I don’t have an answer for that, nor have I worked at a company that found the perfect balance. Plus, I’m not a technical lead, manager, or business owner. So if you are one of them, I’d love to hear how you or your organization plans to tackle this I'm a technical lead, business owner, and ex-manager. So I guess I qualify to answer :) The short answer is that we have only ever had a very (very) small development team. Typically around 3 or 4 people. Secondly we're using "old" tech, nut with up-to-date tooling. Our product contains code written in 1996 and iterated on since. I'm lazy, and I'm not interested in writing it all again in some new language. So we haven't done that. I'm lazy, so I'm not interested in re-architecting it every 5 minutes. I'm lazy so i prefer simple, maintainable, easy to read, code over cleverness. Most of all, as a startup (boot strapped) I didn't get paid in we didn't make sales. (That happened a lot in the early years.) So shipping is a priority. Business is a priority. But since I'm lazy I avoid solutions that'll break things, that'll cause unnecessary work in the future. I have enough autonomy to dictate pace of delivery. I have enough incentive to move the business forward (in the short and long term.) I don't need to resume pad (this is the first ,and last, job I'll ever have.) Alas none of this advice is transferable. What works for me likely won't work for you. Our context is likely too different. So yeah, there are businesses in between the extremes. Ones with competent developers. Ones either competant managers. Ones where all the business interests are kept in balance. They are not easy to find. Good luck.

safety1st 3y ago
As a dev turned entrepreneur one thing I will do when selling projects is talk to clients about software as a depreciating asset. While there are some limitations to the comparison this framing makes sense to business people in general, especially well with finance or operations departments, and can work with internal stakeholders too. The sources of the depreciation are tech debt and general turnover/churn in the method and process within an industry/vertical (like if you built a web app in 2002 based on ASP.NET, it's pretty tough for that to be a lively project today). We know there are systems out there that have been running well and doing their job for 30 years, and there are systems that need to be replaced/rewritten from scratch every couple of years. Which one do you want to buy/fund/budget for? If the customer or stakeholder only cares about a two year horizon you approach the project one way. If they say they want this thing to be firing on all cylinders 10 years from now then we approach it and price or budget for it differently. When you talk like this it doesn't sound too weird to introduce the idea that we should do an annual tune-up to a system that they don't want to have to replace until 2035. The tune-up is how you get 15 years of life out of your intellectual property instead of 10, this is how you sell time to pay down tech debt. The eventual rebuild is also part of the discussion (not if it will happen, because it will. But when it will happen is something we can influence, so the framing can be, would you rather do an expensive rebuild every 10 years, or do it in 15-20 because you paid for a regular maintenance along the way?). Boom now in their head this software you're writing is like a car. Everyone understands cars. A car has a lifespan. If you didn't go to the mechanic and do your annual scheduled maintenance and the car breaks down, that's what you get for being cheap. Like I said big ops and finance departments actually really like the idea of a tuneup that prevents the car from breaking down. They're used to thinking about that with lots of physical assets anyway. A marketing department at a startup maybe not so much but their time horizon is usually short anyway.
- rahkiin 3y ago
  Thank you, this is very insightful and I might try this to explain software.
- _glass 3y ago
  This is very valid and well written. One point I like to stress is the external context I often observed for why it is deprecating. As a company grows initial architectural decisions become more of a burden. So even though some software is running just fine for the specific business case, your new stack can do 80% but also a lot more. This is my way of selling modular solutions, where you can easily take away things and put new things into place.
  - safety1st 3y ago
    Yes, that's a great point. Once we think of a software system as a depreciating asset we start to see a number of factors which are beyond our control. Another example when we're building web apps is that the competitive landscape has changed - * 15 years ago no one expected their website to work well on a phone, or serve up much in the way of streaming video. * 10 years ago no one was expecting that a server should respond in under a second, aka Lighthouse's TTFB, and the concept of say a "Largest Contentful Paint" did not exist. We can go on forever, so what has happened is that all the practices and expectations within the industry have been redefined (occasionally even for good reason!). To stick with the car analogy, you don't expect much in the way of self-driving features from an older car... hell power windows didn't even become ubiquitous until the 1990s. So maybe we just can't get a great TTFB and LCP out of our old dependency stack which existed before those concepts were really a thing, and there you have an example of why a rebuild will probably continue to be a "when" rather than an "if" for years to come. Now we can frame the discussion as "let's partner up to ensure we make the best use out of this system and extend its life as much as is reasonable," which doesn't have to be an adversarial discussion.
- mrphoebs 3y ago
  This is an insightful way of communicating technical and domain debt that software can accrue over time. Thanks.
ChrisMarshallNY 3y ago
I remember reading an article (linked from here, I believe), written by a former PornHub developer. He talked about how the whole thing relies on "boring" tech, like PHP. Probably second only to Google, for hits per second. Uptime, robustness, and ease of maintenance were a really big deal. Very mercenary, and very practical.
rednafi 3y ago
>>> I'm lazy, and I'm not interested in writing it all again in some new language. So we haven't done that. I'm lazy, so I'm not interested in re-architecting it every 5 minutes. I'm lazy so i prefer simple, maintainable, easy to read, code over cleverness. Love this.

safety1st 3y ago

As a dev turned entrepreneur one thing I will do when selling projects is talk to clients about software as a depreciating asset. While there are some limitations to the comparison this framing makes sense to business people in general, especially well with finance or operations departments, and can work with internal stakeholders too. The sources of the depreciation are tech debt and general turnover/churn in the method and process within an industry/vertical (like if you built a web app in 2002 based on ASP.NET, it's pretty tough for that to be a lively project today). We know there are systems out there that have been running well and doing their job for 30 years, and there are systems that need to be replaced/rewritten from scratch every couple of years. Which one do you want to buy/fund/budget for? If the customer or stakeholder only cares about a two year horizon you approach the project one way. If they say they want this thing to be firing on all cylinders 10 years from now then we approach it and price or budget for it differently. When you talk like this it doesn't sound too weird to introduce the idea that we should do an annual tune-up to a system that they don't want to have to replace until 2035. The tune-up is how you get 15 years of life out of your intellectual property instead of 10, this is how you sell time to pay down tech debt. The eventual rebuild is also part of the discussion (not if it will happen, because it will. But when it will happen is something we can influence, so the framing can be, would you rather do an expensive rebuild every 10 years, or do it in 15-20 because you paid for a regular maintenance along the way?). Boom now in their head this software you're writing is like a car. Everyone understands cars. A car has a lifespan. If you didn't go to the mechanic and do your annual scheduled maintenance and the car breaks down, that's what you get for being cheap. Like I said big ops and finance departments actually really like the idea of a tuneup that prevents the car from breaking down. They're used to thinking about that with lots of physical assets anyway. A marketing department at a startup maybe not so much but their time horizon is usually short anyway.

rahkiin 3y ago
Thank you, this is very insightful and I might try this to explain software.
_glass 3y ago
This is very valid and well written. One point I like to stress is the external context I often observed for why it is deprecating. As a company grows initial architectural decisions become more of a burden. So even though some software is running just fine for the specific business case, your new stack can do 80% but also a lot more. This is my way of selling modular solutions, where you can easily take away things and put new things into place.
- safety1st 3y ago
  Yes, that's a great point. Once we think of a software system as a depreciating asset we start to see a number of factors which are beyond our control. Another example when we're building web apps is that the competitive landscape has changed - * 15 years ago no one expected their website to work well on a phone, or serve up much in the way of streaming video. * 10 years ago no one was expecting that a server should respond in under a second, aka Lighthouse's TTFB, and the concept of say a "Largest Contentful Paint" did not exist. We can go on forever, so what has happened is that all the practices and expectations within the industry have been redefined (occasionally even for good reason!). To stick with the car analogy, you don't expect much in the way of self-driving features from an older car... hell power windows didn't even become ubiquitous until the 1990s. So maybe we just can't get a great TTFB and LCP out of our old dependency stack which existed before those concepts were really a thing, and there you have an example of why a rebuild will probably continue to be a "when" rather than an "if" for years to come. Now we can frame the discussion as "let's partner up to ensure we make the best use out of this system and extend its life as much as is reasonable," which doesn't have to be an adversarial discussion.
mrphoebs 3y ago
This is an insightful way of communicating technical and domain debt that software can accrue over time. Thanks.

ChrisMarshallNY 3y ago

I remember reading an article (linked from here, I believe), written by a former PornHub developer. He talked about how the whole thing relies on "boring" tech, like PHP. Probably second only to Google, for hits per second. Uptime, robustness, and ease of maintenance were a really big deal. Very mercenary, and very practical.

rednafi 3y ago

>>> I'm lazy, and I'm not interested in writing it all again in some new language. So we haven't done that. I'm lazy, so I'm not interested in re-architecting it every 5 minutes. I'm lazy so i prefer simple, maintainable, easy to read, code over cleverness. Love this.