Startup Lesson Learned: Technology Doesn’t Matter(thomasbandt.com)
thomasbandt.com
Startup Lesson Learned: Technology Doesn’t Matter
https://thomasbandt.com/startup-lesson-learned-technology-doesnt-matter
23 comments
> - Will this bug fix/change/new feature add new paying customers? - Will this bug fix/change/new feature reduce our customer attrition
Where do things like support and maintenance costs fit in? Developing internal tools to help with administration, spending time refactoring code to improve future maintenance abilities, investing in internal features that will increase scalablity, etc?
That's where a lot of people get sucked into the "new technology" trap as it's tough to know the exact moment that you need to invest in non-customer facing infrastructure as an investment in the future. Twitter is fine now but back in 2010 they infamous for always being down; someone more reliable very easily could have come in and ate their lunch.
Where do things like support and maintenance costs fit in? Developing internal tools to help with administration, spending time refactoring code to improve future maintenance abilities, investing in internal features that will increase scalablity, etc?
That's where a lot of people get sucked into the "new technology" trap as it's tough to know the exact moment that you need to invest in non-customer facing infrastructure as an investment in the future. Twitter is fine now but back in 2010 they infamous for always being down; someone more reliable very easily could have come in and ate their lunch.
I make you right about Twitter. I think my primary point, and what I read in the OPs article is this...don't let the fear and worry about the tech you're using take your eye off the customers paying your bills. I'd much rather have millions of customers using my app while I work out how to fix technical debt issues, than piss about with my choice of tech for 6 months while the competition takes money off of the table. I love technology, but too often it's a distraction in business. Twitter will have known they pushed their luck on reliability while they scaled, and seemingly got the balance right as it didn't take them down.
If you're interested, here's some more specific answers to the points you raised:
So keep in mind we usually have a couple of engineers assigned to the backlog for Staff Squared. Their time is precious, but as with all things a technical solution is not always necessary, so we will often use workarounds:
Internal tools: They exist to help the sales team onboard more customers, or help the support team keep our customers happy, or keep the management team in the loop and so on. Most of these things can be traced back to my two points (getting/keeping customers) and if they can't then they're nice to haves and can wait. Alternatively we'll ask a non-techie member of the team to run a process manually using what they've already got available. We only create a tool if the process we're experimenting with actually delivers enough value to warrant the coding time to automate it.
Internal features that increase scalability. These do go in to the backlog, and they're things like integrating S2 with our CRM, or setting up KPIs (e.g http://imgur.com/itFzSaO) and dashboards for important info. Again, most of these things can be traced back to gaining more customers because we use the data to refine our onboarding and overall user experience, or speaking with customers who aren't as engaged with the app as we would like and ensuring they stay a customer.
Technical debt due to a lack of foresight in code maintenance is not something you want if you can help it. Having said that, I can't think of a bigger technical debt than complex, mature accounting app written in classic ASP running stored procedures to pull data from complex SQL views. So while we do of course have to factor in to sprints things like performance enhancements, code refactors, or just plain old upgrades to the version of .Net MVC we're using, they're just not as much of a priority as my two main justifications for the cards I include in upcoming sprints (Getting customers/keeping customers).
If you're interested, here's some more specific answers to the points you raised:
So keep in mind we usually have a couple of engineers assigned to the backlog for Staff Squared. Their time is precious, but as with all things a technical solution is not always necessary, so we will often use workarounds:
Internal tools: They exist to help the sales team onboard more customers, or help the support team keep our customers happy, or keep the management team in the loop and so on. Most of these things can be traced back to my two points (getting/keeping customers) and if they can't then they're nice to haves and can wait. Alternatively we'll ask a non-techie member of the team to run a process manually using what they've already got available. We only create a tool if the process we're experimenting with actually delivers enough value to warrant the coding time to automate it.
Internal features that increase scalability. These do go in to the backlog, and they're things like integrating S2 with our CRM, or setting up KPIs (e.g http://imgur.com/itFzSaO) and dashboards for important info. Again, most of these things can be traced back to gaining more customers because we use the data to refine our onboarding and overall user experience, or speaking with customers who aren't as engaged with the app as we would like and ensuring they stay a customer.
Technical debt due to a lack of foresight in code maintenance is not something you want if you can help it. Having said that, I can't think of a bigger technical debt than complex, mature accounting app written in classic ASP running stored procedures to pull data from complex SQL views. So while we do of course have to factor in to sprints things like performance enhancements, code refactors, or just plain old upgrades to the version of .Net MVC we're using, they're just not as much of a priority as my two main justifications for the cards I include in upcoming sprints (Getting customers/keeping customers).
Agreed with the interpretation of the OP's article and agree with the general sentiment of building something that's perfect on the backend while ignoring the need to get customers is just wrong.
That said, for anyone reading this, only a sith deals in absolutes and I'd like to share my experience of working with two companies that thought it was fine for tech to take a back seat and for customers to be the driving point.
The first company was an erp company. They still run on fox pro. Yes. Fox pro. They've built a relatively feature stable foundation which they can keep selling to customers. Great right? Customers clearly don't care about the tech running in the background. If you are in there just for the money that works I guess. And that was the problem of customers over tech approach. The UIs were shoddy. There were bugs. The UX ended up making users go through frustrating processes to complete tasks. Report generation was slow. There was a mountain or two of technical debt in the code base that had no tests. And while the money kept rolling in, it felt wrong to keep pushing the product when it wasn't something we ourselves couldn't fall in love with.
The second example is an ecommerce company that I worked at that kept pushing ahead with feature after feature on one tight deadline to a tighter deadline right after. The result was a system that eventually started seeing >10 second load times. We also had a process where customers would come and pay us offline (online payments are still in early days where I am) and the system would slow down heavily during peak hours. But again, the customers were coming so my personal feelings on long load times and long wait times was just nonsense right? Again. Money or love? Which comes first?
At this point I need to say that my personal choice is love first. If making money means I have to sacrifice the love for the experience I'd rather not do it at all. This is just the other side of the coin of going (IMO) deep into the mantra of 'customers don't care about tech'.
Ultimately this is just my opinion. I thought it would be worth sharing. Cheers :)
That said, for anyone reading this, only a sith deals in absolutes and I'd like to share my experience of working with two companies that thought it was fine for tech to take a back seat and for customers to be the driving point.
The first company was an erp company. They still run on fox pro. Yes. Fox pro. They've built a relatively feature stable foundation which they can keep selling to customers. Great right? Customers clearly don't care about the tech running in the background. If you are in there just for the money that works I guess. And that was the problem of customers over tech approach. The UIs were shoddy. There were bugs. The UX ended up making users go through frustrating processes to complete tasks. Report generation was slow. There was a mountain or two of technical debt in the code base that had no tests. And while the money kept rolling in, it felt wrong to keep pushing the product when it wasn't something we ourselves couldn't fall in love with.
The second example is an ecommerce company that I worked at that kept pushing ahead with feature after feature on one tight deadline to a tighter deadline right after. The result was a system that eventually started seeing >10 second load times. We also had a process where customers would come and pay us offline (online payments are still in early days where I am) and the system would slow down heavily during peak hours. But again, the customers were coming so my personal feelings on long load times and long wait times was just nonsense right? Again. Money or love? Which comes first?
At this point I need to say that my personal choice is love first. If making money means I have to sacrifice the love for the experience I'd rather not do it at all. This is just the other side of the coin of going (IMO) deep into the mantra of 'customers don't care about tech'.
Ultimately this is just my opinion. I thought it would be worth sharing. Cheers :)
While I agree with the content, this is another one of those misleading titles. As the author comes to reveal over the course of his post, the technology absolutely matters. Using a technology because it is cool and not because it is the best fit for the problem will lead to failure as surely as using the wrong material in a construction project will cause a build-out to fail.
The other point he makes is use what you know, or get people who have the necessary knowledge. Knowledge matters more than technology, but technology matters.
The other point he makes is use what you know, or get people who have the necessary knowledge. Knowledge matters more than technology, but technology matters.
>- Will this bug fix/change/new feature add new paying customers?
>- Will this bug fix/change/new feature reduce our customer attrition
> If it doesn't tick one of those two boxes, it doesn't go in.
What about security fixes? Or secure coding practices? How do those fit in?
That aside, the attitude above seems like a good way to quickly get deep into technical debt.
>- Will this bug fix/change/new feature reduce our customer attrition
> If it doesn't tick one of those two boxes, it doesn't go in.
What about security fixes? Or secure coding practices? How do those fit in?
That aside, the attitude above seems like a good way to quickly get deep into technical debt.
Hopefully I've explained enough about my approach to technical debt in my response above. I think the problem of not being able to pay the bills due to a lack of customers is much more difficult to overcome than any issues caused by technical debt. More customers usually means more money which buys you time.
> What about security fixes? Or secure coding practices? How do those fit in?
I suspect that, sad as it is, a profit-making business probably shouldn't spend much effort on those - the financial cost/benefit is pretty poor. Customers are overwhelmingly indifferent to being hacked.
I suspect that, sad as it is, a profit-making business probably shouldn't spend much effort on those - the financial cost/benefit is pretty poor. Customers are overwhelmingly indifferent to being hacked.
Well our customers might be but I'm definitely not. Even a sniff of a security issue would be enough for us to drop everything and work to get it investigated. A loss in customer faith for a brand or product is a tough thing to restore.
Well, that depends. I completely agree that needlessly messing around with the cool-database-of-the-week was inadvisable and a waste of time.
But sometimes it's necessary to learn something new. I'm a rails dev who's recently started what is basically a multiplayer game, and which will require many simultaneous connections. I don't know if you know Rails, but it is basically the worst possible technology to use for such a requirement.
It would be ridiculous for me to commence work on a project knowing I was using the wrong tool for the job and that I'd have to rewrite completely if we ever went above 10 or so users. So I'm learning and using something else, and I think that's the right decision.
The trick is in being able to tell when to go with the tried and tested, and when to jump into the new tech. That comes from experience, and you've just gained some :)
But sometimes it's necessary to learn something new. I'm a rails dev who's recently started what is basically a multiplayer game, and which will require many simultaneous connections. I don't know if you know Rails, but it is basically the worst possible technology to use for such a requirement.
It would be ridiculous for me to commence work on a project knowing I was using the wrong tool for the job and that I'd have to rewrite completely if we ever went above 10 or so users. So I'm learning and using something else, and I think that's the right decision.
The trick is in being able to tell when to go with the tried and tested, and when to jump into the new tech. That comes from experience, and you've just gained some :)
I definitely agree with this. I even wrote a blog post expanding around this idea! Thanks for the inspiration. http://www.mystartup.fail/post/110331046850/how-to-choose-a-...
There are two basic types of companies: (1) technology companies and (2) companies that use technology. There is a gray area of course but you are likely either one or the other. Most companies fall into category (2) so in general your technology is entirely focused on serving the needs of the business. Pick the best technologies to serve the business now and in the future. The "cool new stuff" might be a good fit to serve the business but mostly it's not.
You can't be innovative on the full stack. But you need to be innovative somewhere, otherwise your company will fail just like your predecessors (there are predecessors who failed in your space, right?)
Know what your USP is, and use technology to achieve that. Sometimes new technology lets you do things that simply wouldn't be possible otherwise (I spend a lot of my professional life cursing Spark, but the whole business is built on dealing with a volume of data that simply couldn't be processed without it). For other companies, the technology can be your "edge"; if it's a mature market with established competitors, being more willing to push the technological envelope could be the thing that lets you offer lower prices and higher quality; a couple of my previous employers have succeeded by doing exactly that, in relatively "boring" industries.
But if you've got an innovative, experimental business model, you probably don't need innovative, experimental technology as well (and vice versa). Know which parts of your business are the innovation, and which parts are commodity.
Know what your USP is, and use technology to achieve that. Sometimes new technology lets you do things that simply wouldn't be possible otherwise (I spend a lot of my professional life cursing Spark, but the whole business is built on dealing with a volume of data that simply couldn't be processed without it). For other companies, the technology can be your "edge"; if it's a mature market with established competitors, being more willing to push the technological envelope could be the thing that lets you offer lower prices and higher quality; a couple of my previous employers have succeeded by doing exactly that, in relatively "boring" industries.
But if you've got an innovative, experimental business model, you probably don't need innovative, experimental technology as well (and vice versa). Know which parts of your business are the innovation, and which parts are commodity.
Technology does not really matter if you are not a technology company. Most so called tech startups are not really technology companies. A technology company is a company in which the most important added value is the solution to nontrivial technical problems. You are a technology company if you create video cards, VR headsets, rendering engines, game engines, machine translation or speech recognition engines, etc... (These are difficult markets, as the bar is usually very high.) You are not really a tech company if you create a web app that serves web pages from a database however important user need you serve or however successful you are. The problem comes when people want to be technically creative at solving problems which need other kind of creativity (usually business creativity).
He used a database he didn't know how to use, switched to another one he didn't know how to use because someone said it was better, then switched back to the first one, and then switched to another database. There's a problem here, but it isn't using new technology.
To be fair, I think the OP realizes the mistake he made. His post is trying to warn others to not make the same mistake.
I think the thing you're rightfully reacting to is the clickbaity headline.
I think the thing you're rightfully reacting to is the clickbaity headline.
Reading this post, it seems like the technology did matter. Go with the mature option that is well know, rather than wasting time messing around with the latest hipster crap.
It doesn't matter nearly as much as having a finished (if technically non-optimal) product/service you can sell to customers.
The latest hipster crap is more likely to waste your time than something old and established, but even then, choice-of-stack matters much less than 'Can we finish this, and does anyone want to buy it if we do?'
The basic open source problem is that developing code for a 'Show HN' slot or improving imaginary GitHub karma is not the same as building a viable business idea around a web and/or mobile service.
There is no GitHub for business models. The ultimate karma comes from customers.
The latest hipster crap is more likely to waste your time than something old and established, but even then, choice-of-stack matters much less than 'Can we finish this, and does anyone want to buy it if we do?'
The basic open source problem is that developing code for a 'Show HN' slot or improving imaginary GitHub karma is not the same as building a viable business idea around a web and/or mobile service.
There is no GitHub for business models. The ultimate karma comes from customers.
Except that the article cites tool selection as a major botleneck in "can we finish this":
"Instead of focussing on your user’s needs and building a product that everybody wants, you’re wasting your time and burn money by exploring and introducing new technologies."
"Instead of focussing on your user’s needs and building a product that everybody wants, you’re wasting your time and burn money by exploring and introducing new technologies."
Sometimes that latest trendy framework actually is a much better approach. Wanna know how you can tell the difference? Experience.
I used React for the first time when I started building the first version of our MVP because I was familiar with and frustrated with every other front-end approach in Javascript. Angular and Ember were bulky and slow. jQuery and vanilla JS are god damned nightmares for complex interactive applications. Because I have been writing rich client applications in Javascript for the better part of a decade I could very easily assess the pros and cons of React and realize just how great of a tool it was. The same goes for why I use Browserify and why I still use Make (and not grunt or gulp, yuk) for my builds.
The database I went with? Postgres. Redis is the only NoSQL tool in my belt and I use it as basically a sophisticated caching layer, although now that Postgres has such great support for JSON documents I might be fine without it.
I know for sure that there will be new tools in the future. Most will be new versions of an old approach but implemented poorly. A few will be much better and will have a major increase in productivity.
I used React for the first time when I started building the first version of our MVP because I was familiar with and frustrated with every other front-end approach in Javascript. Angular and Ember were bulky and slow. jQuery and vanilla JS are god damned nightmares for complex interactive applications. Because I have been writing rich client applications in Javascript for the better part of a decade I could very easily assess the pros and cons of React and realize just how great of a tool it was. The same goes for why I use Browserify and why I still use Make (and not grunt or gulp, yuk) for my builds.
The database I went with? Postgres. Redis is the only NoSQL tool in my belt and I use it as basically a sophisticated caching layer, although now that Postgres has such great support for JSON documents I might be fine without it.
I know for sure that there will be new tools in the future. Most will be new versions of an old approach but implemented poorly. A few will be much better and will have a major increase in productivity.
I agree with part of his argument - if you're figuring out the direction of your product, it's more efficient to use whatever technology you're most versed in - you don't have the time to spare on learning new things and making all the mistakes associated with that.
We had a very similar experience with FeatureMap. Started off with RavenDB, got tired of all sorts of technical problems (migrations, map/reduce, transactions, deadlocks, ...), quickly rewrote the data layer to use good ol' Entity Framework + SQL Server, and voilà, all better now.
Looking back at this it seems clear now that the way we used RavenDB (it could have been any NoSQL database) was not optimal and that most of the problems we faced were a direct consequence of our naive/simplistic approach. From a personal/technical point of view I don't regret the experience and I now have plenty of ideas about how to better leverage NoSQL databases, but from the business/customer point of view it certainly costed us.
Looking back at this it seems clear now that the way we used RavenDB (it could have been any NoSQL database) was not optimal and that most of the problems we faced were a direct consequence of our naive/simplistic approach. From a personal/technical point of view I don't regret the experience and I now have plenty of ideas about how to better leverage NoSQL databases, but from the business/customer point of view it certainly costed us.
Technology does matter. It matters if you need it to achieve a certain feature (recurrent neural nets demand a certain level of technology, for example). Competing technologies, matter less. But every decision is debt forming. So future-ready tech is better.
Are you sure?
http://www.paulgraham.com/avg.html
Technology always matters.
Luckily you have already picked one of the best available: .NET ecosystem.
Also:
"And if you’re not building something completely new and patentable not a single of your (potential) investors will ever care about the latest fancy JavaScript framework, database, or programming language you’re using."
How about Unity3D? Not new, not patentable, but Mono and C# was an ideal choice. It mattered to them, it mattered to investors.
http://www.paulgraham.com/avg.html
Technology always matters.
Luckily you have already picked one of the best available: .NET ecosystem.
Also:
"And if you’re not building something completely new and patentable not a single of your (potential) investors will ever care about the latest fancy JavaScript framework, database, or programming language you’re using."
How about Unity3D? Not new, not patentable, but Mono and C# was an ideal choice. It mattered to them, it mattered to investors.
You're right, my arguments don't apply to all kind of businesses. The same is correct for Xamarin for example. But if you take JetBrains – no one cares how WebStorm or ReSharper are built internally, as long as they do the job.
I would not discard choosing a "new" technology (term "new" gets a little ambiguous here), especially if it's been around for a few years and preliminary research into it shows promise in regards to my project. I've seen too many companies failing projects because of "When your only tool is a hammer, every problem looks like a nail" situation.
Fully agree.
This is why on many projects I am responsible for, the team has to provide a business value for the customer for new technology.
What it means in terms of $$$ for the customer to have the project adopt technology X.
If it improves the revenue then sure, if it is only for playing with new tech, then do it at home.
This is why on many projects I am responsible for, the team has to provide a business value for the customer for new technology.
What it means in terms of $$$ for the customer to have the project adopt technology X.
If it improves the revenue then sure, if it is only for playing with new tech, then do it at home.
This is so true but isn't limited just to your technology stack. Marketing and sales are also prime candidates for chasing the latest shiny object...but the fundamentals are fundamental for a reason and what you know best should be your first avenue of attack.
Um, the takeaway I get from the post is that Technology DOES matter, and you should make sure it fits your requirements.
If anything, do not go for the latest/shiniest thing on the market, if you are unsure it provides solid advantages on more mature, proven solutions.
If anything, do not go for the latest/shiniest thing on the market, if you are unsure it provides solid advantages on more mature, proven solutions.
Try making your experiments smaller. Lower the cost of failure. Don't stop experimenting.
Technology can matter, if you know how to use it. From your story it seems you guys went in blindfolded and just decided upon the technology on a hunch. That is your fault, not the technology.
I disagree fully with his assertions. Technology stack will make or break a company.
You're going to have pick new technologies, changes are happening. Are you going to roll a one page app with just JQuery? Of course not. Are you going build a 100TB datawarehouse on top of mysql? Are you going to build your infrastructure off bare metal server? Even source control has changed. How many people still use SVN?
Most important takeway from the article is keep things simple. Picking a complex technology for a simple problem will cause you pain. Both in the development environment and also in production.
You're going to have pick new technologies, changes are happening. Are you going to roll a one page app with just JQuery? Of course not. Are you going build a 100TB datawarehouse on top of mysql? Are you going to build your infrastructure off bare metal server? Even source control has changed. How many people still use SVN?
Most important takeway from the article is keep things simple. Picking a complex technology for a simple problem will cause you pain. Both in the development environment and also in production.
While broadly the OP is fully correct,
actually the statement
> Technology Doesn’t Matter
is over stated.
First, to be more clear, we need to consider what we mean by technology: In the OP, an example is some software framework -- for that, sure, especially in the context of the OP, likely such technology "doesn't matter". Why? In terms from 100,000 feet up, we're still talking, say, Turing machine equivalent so that we should still be able to get the software written without some particular framework. And, following the OP where it recommended staying with the technology the team already knew, the new technology likely will not be much or any more effective, efficient, etc., at least in the short term, for the project at hand.
But, I believe that the OP is missing an important point, one that, in my opinion (IMO), your mileage may vary (YMMV), is too often missed:
First, for context, assume that the project is to solve a problem where a good solution will be quite valuable but apparently also quite challenging technically. Or, the nature of the challenge is, say, "How the heck is it even possible to do that?".
Second, let's focus on just the technical part of the solution, that is, on the challenge:
For this focus, let's have an example where the technology very much did matter.
Ike wanted some pictures. The U-2 reconnaissance airplane was too slow and too low, and, thus, too vulnerable to being shot down, and he needed a plane that would fly higher and faster, enough of both so that it would be much more difficult to shoot down.
So, flying at 80,000+ feet at Mach 3.0+ should suffice. And, by the way, need range 2000+ miles without refueling.
A challenge: Put two really large turbojet engines in an otherwise really small airplane and can get thrust enough for Mach 3.0+, but some aerodynamics says that at such speeds the air into the engine, as it slows down to subsonic speed as needed by the compressor stage, can get so hot it will cause major parts of the engine to overheat, i.e., burn out. There was at one time at least one MIG 25 pilot who could confirm this point.
Relevant technology:
(1) There was a unit of Pratt and Whitney in Florida that considered such jet engine problems and had a bright idea: At Mach 2.5+ or so, don't really need the turbojet compressor. Instead, treat the engine just as a ram jet. So, take the input air, let it bypass the usual compressor and turbine stages, let it enter at essentially the usual afterburner stage, add fuel, and go. Bright idea. And, yes, they made it work.
(2) At Mach 3.0+, even at 80,000 feet, the friction, etc., of the air gets the surface of the airplane hot. So, need, say, stainless steel or titanium. The MIG 25 used stainless steel.
Well, at Lockheed, Kelly Johnson considered the Pratt and Whitney engine and titanium and designed and built a few dozen of the the SR-71s; Ike got his pictures; and no SR-71 was lost to enemy action.
So, the engine and the titanium were technology that very much did "matter".
And there are more examples from the past, and there may be more examples in the future, that is, where technology very much does "matter".
Not all possibly relevant technology, even for software projects, is just software frameworks, etc. as considered in the OP.
> Technology Doesn’t Matter
is over stated.
First, to be more clear, we need to consider what we mean by technology: In the OP, an example is some software framework -- for that, sure, especially in the context of the OP, likely such technology "doesn't matter". Why? In terms from 100,000 feet up, we're still talking, say, Turing machine equivalent so that we should still be able to get the software written without some particular framework. And, following the OP where it recommended staying with the technology the team already knew, the new technology likely will not be much or any more effective, efficient, etc., at least in the short term, for the project at hand.
But, I believe that the OP is missing an important point, one that, in my opinion (IMO), your mileage may vary (YMMV), is too often missed:
First, for context, assume that the project is to solve a problem where a good solution will be quite valuable but apparently also quite challenging technically. Or, the nature of the challenge is, say, "How the heck is it even possible to do that?".
Second, let's focus on just the technical part of the solution, that is, on the challenge:
For this focus, let's have an example where the technology very much did matter.
Ike wanted some pictures. The U-2 reconnaissance airplane was too slow and too low, and, thus, too vulnerable to being shot down, and he needed a plane that would fly higher and faster, enough of both so that it would be much more difficult to shoot down.
So, flying at 80,000+ feet at Mach 3.0+ should suffice. And, by the way, need range 2000+ miles without refueling.
A challenge: Put two really large turbojet engines in an otherwise really small airplane and can get thrust enough for Mach 3.0+, but some aerodynamics says that at such speeds the air into the engine, as it slows down to subsonic speed as needed by the compressor stage, can get so hot it will cause major parts of the engine to overheat, i.e., burn out. There was at one time at least one MIG 25 pilot who could confirm this point.
Relevant technology:
(1) There was a unit of Pratt and Whitney in Florida that considered such jet engine problems and had a bright idea: At Mach 2.5+ or so, don't really need the turbojet compressor. Instead, treat the engine just as a ram jet. So, take the input air, let it bypass the usual compressor and turbine stages, let it enter at essentially the usual afterburner stage, add fuel, and go. Bright idea. And, yes, they made it work.
(2) At Mach 3.0+, even at 80,000 feet, the friction, etc., of the air gets the surface of the airplane hot. So, need, say, stainless steel or titanium. The MIG 25 used stainless steel.
Well, at Lockheed, Kelly Johnson considered the Pratt and Whitney engine and titanium and designed and built a few dozen of the the SR-71s; Ike got his pictures; and no SR-71 was lost to enemy action.
So, the engine and the titanium were technology that very much did "matter".
And there are more examples from the past, and there may be more examples in the future, that is, where technology very much does "matter".
Not all possibly relevant technology, even for software projects, is just software frameworks, etc. as considered in the OP.
I find this argument very uncompelling. This product sounds like it never exited mvp if sql server free was to be good enough. I'll agree that at small scale there are lots of potential technologies. But it also makes me wonder what was so challenging here that they felt they had to keep swapping around. I won't speculate here.
However I disagree with the premise. At scale this absolutely matters. Different databases have vastly different design goals or cap theorem attributes. You'd better pick the right on or it'll impact your customer xp.
However I disagree with the premise. At scale this absolutely matters. Different databases have vastly different design goals or cap theorem attributes. You'd better pick the right on or it'll impact your customer xp.
> At scale this absolutely matters.
So worry about it when you get to scale, not before. Most products and startups never reach the scale at which such basic technology choices matter; their time is better spent growing the company (adding user features, attracting new users, etc) than fighting with technology.
MySQL was never designed to scale to the levels which Facebook and Google use them. And yet both companies are still using them today, even as the roles they use them in diminish as better technologies are brought to bear.
Technology shortcomings can be worked around, so long as you're still in business.
So worry about it when you get to scale, not before. Most products and startups never reach the scale at which such basic technology choices matter; their time is better spent growing the company (adding user features, attracting new users, etc) than fighting with technology.
MySQL was never designed to scale to the levels which Facebook and Google use them. And yet both companies are still using them today, even as the roles they use them in diminish as better technologies are brought to bear.
Technology shortcomings can be worked around, so long as you're still in business.
> So worry about it when you get to scale, not before.
You are advocating people to spend man years of work just as their company start to get sucessfull porting their codebase, instead of stopping a couple of minutes earlier on to correctly decide what tools they'll need.
You are advocating people to spend man years of work just as their company start to get sucessfull porting their codebase, instead of stopping a couple of minutes earlier on to correctly decide what tools they'll need.
> instead of stopping a couple of minutes earlier on to correctly decide what tools they'll need.
Based on my previous experience, I'm advocating exactly that. The reasons are:
1) Bikeshedding - Everyone knows that N technology is better than M technology, even if nobody has real work experience with N
2) Starting with a new technology that people have only done side projects in costs significantly more time than just a few minutes.
2a) Nobody knows what those costs will be before hand
3) By the time you actually have to spend those "man years", committing resources those "man years" of effort won't negatively impact your ability to reach new customers.
3a) This work will not be required "just as their company start to get sucessfull", but at some point after that.
3b) You will most likely not have to do a full re-write all at once. Small refactorings of the actual pain points is how its typically done (there are plenty of examples of this in the marketplace today - Google, Facebook, Twitter)
4) Premature optimization, YAGNI, DRY, etc. all apply to your technology choice as much as they do your codebase.
Based on my previous experience, I'm advocating exactly that. The reasons are:
1) Bikeshedding - Everyone knows that N technology is better than M technology, even if nobody has real work experience with N
2) Starting with a new technology that people have only done side projects in costs significantly more time than just a few minutes.
2a) Nobody knows what those costs will be before hand
3) By the time you actually have to spend those "man years", committing resources those "man years" of effort won't negatively impact your ability to reach new customers.
3a) This work will not be required "just as their company start to get sucessfull", but at some point after that.
3b) You will most likely not have to do a full re-write all at once. Small refactorings of the actual pain points is how its typically done (there are plenty of examples of this in the marketplace today - Google, Facebook, Twitter)
4) Premature optimization, YAGNI, DRY, etc. all apply to your technology choice as much as they do your codebase.
For some values of startup, this all makes sense. If you're trying to solve a hard computing problem (not a social problem) then you have to write your own code. Turns out open source rarely gets around to hardening their code.
The you get to decide - jump aboard some community and try to help them get the code where you need it, or write your own. The community sounds nice, but the thrashing there can add more work than it's worth - tracking (incompatible) changes, arguing for your APIs and layering etc. Doubles the job at least.
Then you write your own. Again time wasted but not how you think. With examples of working code and/or a good idea what you need, you write it and it works. But you spend the rest of your life defending your decision. Every new hire naievely says "you could just have used node.js!" And you try to walk them down the design points but its almost hopeless.
I'm maybe a little depressed about this right now. My startup just got refinanced under the condition we use open source for everything, and write our app as a web app. Which of course is a pipe dream, since our app does hard things using carefully written low-level code, complex network strategies and heuristics hard-won from a thousand customer issues met and solved.
But no! Chrome can do all that, for free! So I'm asked to quit being a not-invented-here drudge and jump on board.
Anybody hiring?
The you get to decide - jump aboard some community and try to help them get the code where you need it, or write your own. The community sounds nice, but the thrashing there can add more work than it's worth - tracking (incompatible) changes, arguing for your APIs and layering etc. Doubles the job at least.
Then you write your own. Again time wasted but not how you think. With examples of working code and/or a good idea what you need, you write it and it works. But you spend the rest of your life defending your decision. Every new hire naievely says "you could just have used node.js!" And you try to walk them down the design points but its almost hopeless.
I'm maybe a little depressed about this right now. My startup just got refinanced under the condition we use open source for everything, and write our app as a web app. Which of course is a pipe dream, since our app does hard things using carefully written low-level code, complex network strategies and heuristics hard-won from a thousand customer issues met and solved.
But no! Chrome can do all that, for free! So I'm asked to quit being a not-invented-here drudge and jump on board.
Anybody hiring?
Ugh. Good luck with that... Maybe you can pull a "Breach" and only use Chrome as your, well, Chrome.
http://breach.cc/
http://breach.cc/
People who've made bad technological choices and then claiming "technology doesn't matter" just because they fucked up are about as annoying as people who always want to use the latest new shiny toys.
You just made the wrong choices at the wrong time for the wrong reasons. Period.
That doesn't say fuck all about the next guy who may have perfectly good reasons to either choose the next new bleeding edge shiny or go with tried and proven old tech.
The final sentence is the worst advice possible. Never, ever stop experimenting. Just properly separate experimenting from building.
And please stop lecturing other people because you can't keep that shit apart.
You just made the wrong choices at the wrong time for the wrong reasons. Period.
That doesn't say fuck all about the next guy who may have perfectly good reasons to either choose the next new bleeding edge shiny or go with tried and proven old tech.
The final sentence is the worst advice possible. Never, ever stop experimenting. Just properly separate experimenting from building.
And please stop lecturing other people because you can't keep that shit apart.
BY your logic I should be experimenting wit a load of NoSQL databases. Except I can see that in my situation they give me precisely zero benefit over a Postgres (except for some buzzwords on my CV). I can see that many of the NoSQL key value stores are not much different from a Perl hash tied to Berkley DB - I tried that 6 or 7 years ago - it can useful but fairly limited.
No, that wasn't his logic. NoSQL data bases aren't the only tech that is worth experimenting with.
I have a friend that built and sold an online accounting app for £XX millions (yep, that's two x's there) a year or so ago. He originally created the app using classic ASP, as that was all he knew at the time. After a few years of growth they started to build a .Net version of the app but it never saw the light of day. Guess why? Because they were too busy growing the company and ultimately selling it. And this is exactly the right approach. I'm pretty sure with hindsight he wouldn't have bothered with the .Net version of the app.
It's way too easy to get bogged down in using <latest trendy frameworks>, <trendiest latest NoSQL> or some other technical bullshit that doesn't actually add value for your customers. I know because I've done it and wasted far too many hours of precious development time.
So now whenever I'm reviewing the list of cards in Trello for the next sprint on our app http://www.staffsquared.com I ask myself two very simple questions:
- Will this bug fix/change/new feature add new paying customers?
- Will this bug fix/change/new feature reduce our customer attrition
If it doesn't tick one of those two boxes, it doesn't go in.