3 ms·

> Anybody can explain why SQL database makes sense for large time series data? Let's say, just to say, that you have effectively free licensing for Microsoft S

> Anybody can explain why SQL database makes sense for large time series data? Let's say, just to say, that you have effectively free licensing for Microsoft SQL Server (because you already own the licenses in question), and you have staff who know that platform well. Sometimes it's easier to use the tools you already have rather than go acquire a new platform to achieve a goal. As with anytime you choose a persistence layer, you're accumulating technical debt the instant you make the choice. Over time, if better persistence layers become available, you have to make a judgment call about when it makes sense to change the code, versus when it makes sense to do maintenance work on the persistence layer.

slg 6y ago
>and you have staff who know that platform well. People often ignore how important this is, especially for a small team like Stack Overflow appears to have. A new platform requires training and/or a lack of productivity as employees learn the new system. It requires developer time to convert over any work designed to use the old system. It makes hiring more difficult because now you will either want someone with the knowledge of both your systems which greatly shrinks down your pool of potential hires or new employees will need to learn a new system on the job which increases the ramp time up for any hires. Maybe this doesn't fit the textbook definition of technical debt, but it is still a real and ongoing cost that comes with making a decision to switch tools.
- gbrayut 6y ago
  Case in point, one of my favorite system architecture/design blog posts: Providence: Failure Is Always An Option https://jasonpunyon.com/blog/2015/02/12/providence-failure-is-always-an-option/ https://jasonpunyon.com/blog/2015/02/12/providence-failure-i... Which has one of my favorite quotes about scope creep: Kevin and I have essentially become allergic to big projects. We attempt to practice “What can get done by Friday?” driven development. Keeping things small precludes a whole class of errors like “We need a new datastore”, ‘cause that ain’t gettin’ done by Friday. It’s hard to sink a week on something you weren’t supposed to be working on when all you have is a week.
nickpeterson 6y ago
I debate this a lot with coworkers. Our industry really loves novelty and new things, but very little expertise is available for new things. I’d rather have an expert at VB6 than a completely new Julia developer.

slg 6y ago

>and you have staff who know that platform well. People often ignore how important this is, especially for a small team like Stack Overflow appears to have. A new platform requires training and/or a lack of productivity as employees learn the new system. It requires developer time to convert over any work designed to use the old system. It makes hiring more difficult because now you will either want someone with the knowledge of both your systems which greatly shrinks down your pool of potential hires or new employees will need to learn a new system on the job which increases the ramp time up for any hires. Maybe this doesn't fit the textbook definition of technical debt, but it is still a real and ongoing cost that comes with making a decision to switch tools.

gbrayut 6y ago
Case in point, one of my favorite system architecture/design blog posts: Providence: Failure Is Always An Option https://jasonpunyon.com/blog/2015/02/12/providence-failure-is-always-an-option/ https://jasonpunyon.com/blog/2015/02/12/providence-failure-i... Which has one of my favorite quotes about scope creep: Kevin and I have essentially become allergic to big projects. We attempt to practice “What can get done by Friday?” driven development. Keeping things small precludes a whole class of errors like “We need a new datastore”, ‘cause that ain’t gettin’ done by Friday. It’s hard to sink a week on something you weren’t supposed to be working on when all you have is a week.

nickpeterson 6y ago

I debate this a lot with coworkers. Our industry really loves novelty and new things, but very little expertise is available for new things. I’d rather have an expert at VB6 than a completely new Julia developer.