How to start and scale a full stack startup(blog.42floors.com)
blog.42floors.com
How to start and scale a full stack startup
http://blog.42floors.com/how-to-start-and-scale-a-full-stack-startup/
27 comments
The whole overloading of "full stack" really bugs me. I lean towards definition (3) above. Software can run front end to back (or some portion there of), but most "full stack developer" gigs kinda stop at above the hardware level.
For me, knowing the right choice of software components best suited to the platform (vms, direct hardware, etc) and how to tweak the platform is as critical as any other layer above it.
For me, knowing the right choice of software components best suited to the platform (vms, direct hardware, etc) and how to tweak the platform is as critical as any other layer above it.
I always thought it was meant to indicate proficiency with all 7 layers of the OSI stack.
So if you can't design and build a network (2 or 3 buildings 2-3k hosts) you are not a full stack developer.
Btw this small network is what CISCO expects a CCNA to be able to do.
So if you can't design and build a network (2 or 3 buildings 2-3k hosts) you are not a full stack developer.
Btw this small network is what CISCO expects a CCNA to be able to do.
I'm just waiting for the Full Stack Cloud to become a thing
Surely that would disrupt the industry. Social, mobile, local!
For me "Full Stack" means: there is no stack.
Its difficult to argue about this with academic reasoning, but my 'feelings' after 30+ years in the software business is that the more you treat the artificial borders between technologies as insignificant, the less significant the effort required to grasp the technology. In other words, there are no real 'borders'; these are self-imposed on the individual programmer, socially, in sometimes very sexy packages. "Framework Developer" is another nasty phrase arising, in my opinion, because what does it mean? You use the framework, or you build one?
Either way, this artificial division allows for the ordering of 'developer skills' in such a way that one higher skilled programmer can sell the other lesser but nevertheless competent, programmer .. something.
There is no Stack, means, if you need to know something about your computer, you can. Dig into its depths faster and with more passion, not slower, because 'there is no way to understand it all' is a fallacy. You can, indeed, understand every single thing that the computer is doing; it was made that way.
Its difficult to argue about this with academic reasoning, but my 'feelings' after 30+ years in the software business is that the more you treat the artificial borders between technologies as insignificant, the less significant the effort required to grasp the technology. In other words, there are no real 'borders'; these are self-imposed on the individual programmer, socially, in sometimes very sexy packages. "Framework Developer" is another nasty phrase arising, in my opinion, because what does it mean? You use the framework, or you build one?
Either way, this artificial division allows for the ordering of 'developer skills' in such a way that one higher skilled programmer can sell the other lesser but nevertheless competent, programmer .. something.
There is no Stack, means, if you need to know something about your computer, you can. Dig into its depths faster and with more passion, not slower, because 'there is no way to understand it all' is a fallacy. You can, indeed, understand every single thing that the computer is doing; it was made that way.
wow - I've been using full stack to mean someone who can go from embedded to OS driver to web backend to web front end - add mobile apps too.
i dislike it though, alas ive succumb to the desire to use the hip title in discussion.
i dislike it though, alas ive succumb to the desire to use the hip title in discussion.
"full stack" == "jack of all trades"
"full stack already has an abundance of meanings depending on who you are talking to"
That's why it's useful! There isn't a pre-existing term that means the same thing exactly, and there is enough need for one that we are seeing it employed in the wild.
That's why it's useful! There isn't a pre-existing term that means the same thing exactly, and there is enough need for one that we are seeing it employed in the wild.
No, there's no need for a new term. From what I've read 'full-stack' in this context is not much different to 'vertically-integrated'. The way it's being used, it's about as useful as 'ninja' or 'rock star' in job ads.
Doesn't full stack just mean decent ability all the way from assembly or C, to web dev or phone apps, pretty much
I think the sad thing here is the idea that code is so expensive and rigid that it's better to slog through something manually, just to avoid the potential of being locked in by code.
I get that sometimes automation sets you on a course of infinite refinement, and you end up investing more money that you should have making some tool cover 100% of all possible use cases. But that doesn't mean you never should have started building the tool, just that you went way too damn far once the "bugs" and "feature requests" came rolling in.
What about the relative costs and risks associated with hiring a workforce for all the manual labor? There's a certain net weight in work that needs to be done, you can shovel it by hand or you can build a machine to help you. How is it not a winning move to hire fewer, smarter people, and empower them with a great software stack?
The goal isn't to build a machine which can do 100% of the work. But whatever the product you sell, you may find you can spend $1 in engineering to reduce the variable cost of delivering that product by more than $1. That's printing money. But to identify these opportunities, and more importantly to prioritize these opportunities and stop working on the BS never-pay-you-back feature, I think you need a project manager who can understand software complexity as well as the business case.
I get that sometimes automation sets you on a course of infinite refinement, and you end up investing more money that you should have making some tool cover 100% of all possible use cases. But that doesn't mean you never should have started building the tool, just that you went way too damn far once the "bugs" and "feature requests" came rolling in.
What about the relative costs and risks associated with hiring a workforce for all the manual labor? There's a certain net weight in work that needs to be done, you can shovel it by hand or you can build a machine to help you. How is it not a winning move to hire fewer, smarter people, and empower them with a great software stack?
The goal isn't to build a machine which can do 100% of the work. But whatever the product you sell, you may find you can spend $1 in engineering to reduce the variable cost of delivering that product by more than $1. That's printing money. But to identify these opportunities, and more importantly to prioritize these opportunities and stop working on the BS never-pay-you-back feature, I think you need a project manager who can understand software complexity as well as the business case.
"code is so expensive and rigid"
For a former embedded systems engineer, this is a hilarious sentiment ... if code you can deploy to your web server two minutes after you've written it is "rigid", I'd hate to see what the current generation of software engineers would think about not being able to "reROM" an embedded device once it was shipped. Even remote-FLASH capabilities are a pretty recent invention.
I think the main problem the article describes is that if you prematurely write software for a perceived problem, you will often be wrong. Writing software will always be more expensive than some number of manual operations, but those manual operations, in the absence of a clear specification and solution, will help you understand the problem domain in ways you wouldn't have otherwise.
For a former embedded systems engineer, this is a hilarious sentiment ... if code you can deploy to your web server two minutes after you've written it is "rigid", I'd hate to see what the current generation of software engineers would think about not being able to "reROM" an embedded device once it was shipped. Even remote-FLASH capabilities are a pretty recent invention.
I think the main problem the article describes is that if you prematurely write software for a perceived problem, you will often be wrong. Writing software will always be more expensive than some number of manual operations, but those manual operations, in the absence of a clear specification and solution, will help you understand the problem domain in ways you wouldn't have otherwise.
I said 'the sad thing is the idea that code is so expensive and rigid'. I personally don't think that code is particularly expensive or rigid at all, perhaps least of all this type of specialized task automation code.
I guess there are two ways that you "will often be wrong" when automating a specific task. 1) You could improperly or so incoherently automate the task that it actually is harder to for your users to accomplish the task with the tool -- failure to improve productivity of the stated task, or 2) you could successfully automate the task at hand, but either the improvement is too minimal, the task is too rare, or the code cannot be well leveraged when the task needs to change, meaning you never get to break-even on the investment. Both failure modes can be well defended against by a good PM.
Are you saying, that by shipping some automation code, now just by nature of having the tool in the workforce's hands, they are actually less able to understand the problem domain and come up with better ways of doing things in the future?
I think of it a bit differently; the automation of a given approach gets so good that a competing idea that could actually produce a better outcome, but must be done completely manually, is so inefficient compared to the automated workflow as to result in a negative effect, and so it's dismissed. (E.g. you earned an extra $10k on this client doing it your way, but if you used the automated fast-path, you could have just closed 5 more clients at $10k each in the same time).
One way I see this often manifest is the idea that sales always wants to be able to say YES to the prospect / client. If you have a large software automation toolset, you only say YES when the needs match the capabilities, because you lose money every time you work on the special-case clients. I think basically you sacrifice growth rate in this case in order to be a jack-of-all-trades.
I guess there are two ways that you "will often be wrong" when automating a specific task. 1) You could improperly or so incoherently automate the task that it actually is harder to for your users to accomplish the task with the tool -- failure to improve productivity of the stated task, or 2) you could successfully automate the task at hand, but either the improvement is too minimal, the task is too rare, or the code cannot be well leveraged when the task needs to change, meaning you never get to break-even on the investment. Both failure modes can be well defended against by a good PM.
Are you saying, that by shipping some automation code, now just by nature of having the tool in the workforce's hands, they are actually less able to understand the problem domain and come up with better ways of doing things in the future?
I think of it a bit differently; the automation of a given approach gets so good that a competing idea that could actually produce a better outcome, but must be done completely manually, is so inefficient compared to the automated workflow as to result in a negative effect, and so it's dismissed. (E.g. you earned an extra $10k on this client doing it your way, but if you used the automated fast-path, you could have just closed 5 more clients at $10k each in the same time).
One way I see this often manifest is the idea that sales always wants to be able to say YES to the prospect / client. If you have a large software automation toolset, you only say YES when the needs match the capabilities, because you lose money every time you work on the special-case clients. I think basically you sacrifice growth rate in this case in order to be a jack-of-all-trades.
I totally missed "the idea" - it seems like we're in violent agreement!
A lot of times you are going into existing, older markets where there isn't just a "set of requirements" to be defined by a good PM. Commercial real estate is a great example. The existing processes in renting are extremely case-by-case and specific. You need to go in and first define how you will start to standardize things, and get buy-in from the industry around that process. So you start with the manual, and then automate as you find fit.
This is different from creating enterprise software as a vendor. When you go to one large corporate and they want software automation added around their process, they usually have a process to be standardized. So then you can just figure out and write up the requirements. When you are building a more generalized, SaaS-type product for an industry as a whole, no one yet even has a vague idea of what the process and requirements are.
This is different from creating enterprise software as a vendor. When you go to one large corporate and they want software automation added around their process, they usually have a process to be standardized. So then you can just figure out and write up the requirements. When you are building a more generalized, SaaS-type product for an industry as a whole, no one yet even has a vague idea of what the process and requirements are.
I don't really consider this example to qualify as a "full stack startup".
If 42floors was a real full stack startup, they would be developing, buying, and selling real estate
If 42floors was a real full stack startup, they would be developing, buying, and selling real estate
I think the author is learning the wrong thing.
Software isn't about automating things, and certainly not about automating things 100%. It's about building tools to leverage people's times (in this context).
If you can build software that makes those folks doing those manual processes 30% more productive, then do so.
He has this idea that you should never build tools by default because automating them 100% is too costly. Automating them 100% may be too costly, stop trying to do that.
Software isn't about automating things, and certainly not about automating things 100%. It's about building tools to leverage people's times (in this context).
If you can build software that makes those folks doing those manual processes 30% more productive, then do so.
He has this idea that you should never build tools by default because automating them 100% is too costly. Automating them 100% may be too costly, stop trying to do that.
Very interesting perspective. I think he goes a bit overboard with saying that everything should be manual by default. Most business are not like real estate in terms of profits in dollars. I think that is giving them the opportunity to hire a lot of inexpensive workers to do all of these manual tasks. That and investment which is naturally attracted go real estate. Anyway it is a good point if a bit overblown in this case. Even internet businesses need tointeract with the real world and changing requirements in a fluid way and that means you can't always have the ultimate integrated automated system. Spreadsheets are very powerful.
Anyone know why 42floors blog posts end up on the front page so often?
Not sure what you mean, i don't see them that much. And they had some good stuff, like about manual scaling: http://blog.42floors.com/manual-scaling/
I was thinking the same thing. I don't come here that often, and this is probably the third one I've seen.
I think with many founders being software engineers themselves, they naturally steer away from manual solutions (and usually with good reason). But some problems, such as those faces by Uber and 42Floors, simply need manual solutions. That's why it's useful for software-oriented founders to also educated themselves in operations and management.
> Start with manual processes
This actually goes for all companies. Early on, whenever you can replace code with a manual process, you should; if for no other reason than it can help you to iterate faster. We do it religiously at 42Floors. Everything starts manually. Save your precious engineering cycles for the times when you actually need it.
God, there needs to be a sexy phrasing of this, kind of like how quick-iteration-cycles has "Move fast and break things." Today, people are so dependent on computers that they seem to forget that there used to be a way to just do things even without an app.
I've helped or consulted on various researching projects for fun, and it always pains me to hear a very smart person say something like, "I saw that there's a great Java library for sentiment analysis. Should we build our project on Java?"
Nevermind the layperson ignorance of software engineering evident in that question...my problem with this kind of question is why do we need any kind of software to do "sentiment analysis"?
The reason isn't self-evident...and if the questioner would just take the time to do "sentiment analysis" manually, as if no computers existed, what they actually need would be easy to explain to a software engineer. And what I mean by "manually", I mean to take a sample of input and a spreadsheet, and then mark down the "sentiment" you yourself can detect by reading over each unit of input.
After an hour of that, you'll have a great idea of what you actually want and need, such as, what kind of sentiment are you looking for? What is the granularity of sentiment, e.g. just "happy" and "angry"? Or do you need "Very happy/happy/neutral/unhappy/angry?" And if the latter, how did you, yourself, as a human, differentiate between an "unhappy" and "angry" input?
You may realize that you don't need very much granularity. Or that the kind of input you're analyzing, such as tweets, do not lend themselves very easily to accurate sentiment analysis...or, at the very least, will require certain tweaks in the software so as not to be thrown off by common styles of phrasing. Or you may find the input lends itself to having a nice loophole that greatly enhances how quickly you can judge sentiment, such as if your input sample tends to use a lot of emoji.
These are all computational thought processes that require no machine learning to just do, that we as humans can do for ourselves, whether it's to efficiently prototype a machine learning model or because an EMP bomb just went off. As a programmer, I'm all for automating the hell out of everything, but it really irks me when people have no idea how to automate something, nor have a reason why something should be automated, and then hope that the machine (or its mercenary operator) can figure it all out for them.
This actually goes for all companies. Early on, whenever you can replace code with a manual process, you should; if for no other reason than it can help you to iterate faster. We do it religiously at 42Floors. Everything starts manually. Save your precious engineering cycles for the times when you actually need it.
God, there needs to be a sexy phrasing of this, kind of like how quick-iteration-cycles has "Move fast and break things." Today, people are so dependent on computers that they seem to forget that there used to be a way to just do things even without an app.
I've helped or consulted on various researching projects for fun, and it always pains me to hear a very smart person say something like, "I saw that there's a great Java library for sentiment analysis. Should we build our project on Java?"
Nevermind the layperson ignorance of software engineering evident in that question...my problem with this kind of question is why do we need any kind of software to do "sentiment analysis"?
The reason isn't self-evident...and if the questioner would just take the time to do "sentiment analysis" manually, as if no computers existed, what they actually need would be easy to explain to a software engineer. And what I mean by "manually", I mean to take a sample of input and a spreadsheet, and then mark down the "sentiment" you yourself can detect by reading over each unit of input.
After an hour of that, you'll have a great idea of what you actually want and need, such as, what kind of sentiment are you looking for? What is the granularity of sentiment, e.g. just "happy" and "angry"? Or do you need "Very happy/happy/neutral/unhappy/angry?" And if the latter, how did you, yourself, as a human, differentiate between an "unhappy" and "angry" input?
You may realize that you don't need very much granularity. Or that the kind of input you're analyzing, such as tweets, do not lend themselves very easily to accurate sentiment analysis...or, at the very least, will require certain tweaks in the software so as not to be thrown off by common styles of phrasing. Or you may find the input lends itself to having a nice loophole that greatly enhances how quickly you can judge sentiment, such as if your input sample tends to use a lot of emoji.
These are all computational thought processes that require no machine learning to just do, that we as humans can do for ourselves, whether it's to efficiently prototype a machine learning model or because an EMP bomb just went off. As a programmer, I'm all for automating the hell out of everything, but it really irks me when people have no idea how to automate something, nor have a reason why something should be automated, and then hope that the machine (or its mercenary operator) can figure it all out for them.
I realized exactly this when I wanted to write a backup script for some of my client's websites.
My usual process had been to 'manually' backup using rsync, which was a matter of cutting and pasting the commands from a text document.
When automating, however, I realized I'd also have to check if certain files (db dumps) were present, and of course if the script itself succeeded.
I then realized that in this particular case, the simple cut and paste approach was perfectly fine, because: 1) it would take months for the time spent automating to be worth it compared to a quick cut and paste, and 2) it was much safer for me to quickly scroll back in my terminal and see if the particular files were present.
Now I wouldn't generally recommend my approach, but in context it made sense not to automate, and yet I felt a 'need' to automate anyways.
My usual process had been to 'manually' backup using rsync, which was a matter of cutting and pasting the commands from a text document.
When automating, however, I realized I'd also have to check if certain files (db dumps) were present, and of course if the script itself succeeded.
I then realized that in this particular case, the simple cut and paste approach was perfectly fine, because: 1) it would take months for the time spent automating to be worth it compared to a quick cut and paste, and 2) it was much safer for me to quickly scroll back in my terminal and see if the particular files were present.
Now I wouldn't generally recommend my approach, but in context it made sense not to automate, and yet I felt a 'need' to automate anyways.
Automating is not just about speeding up the process; it's also a way of lowering the bus factor[1] of the process. What happens when you go on vacations, or you get sick? Do the websites stop being backed up?
Besides, you should always document your process, and writing a backup script doesn't really take much more time than a detailed description in English.
[1] https://en.wikipedia.org/wiki/Bus_factor
Besides, you should always document your process, and writing a backup script doesn't really take much more time than a detailed description in English.
[1] https://en.wikipedia.org/wiki/Bus_factor
Exactly, writing down the steps should be the first step in automating a process. The order I do the steps are:
1. Write down the directions to do the task 2. Have someone else follow your directions. Any time you need to interrupt them because you missed something add a note or additional step 3. See if any part (or the whole thing) is worth automating
1. Write down the directions to do the task 2. Have someone else follow your directions. Any time you need to interrupt them because you missed something add a note or additional step 3. See if any part (or the whole thing) is worth automating
But I guess everyone is learning that this is not a substitute for all the grunt work needed to grow a business. PG wrote it in his "Do Things that Don't Scale" essay:
http://paulgraham.com/ds.html
--
On another note, I hope this term doesn't catch on, because full stack already has an abundance of meanings depending on who you are talking to:
- Full Stack Web Developer (backend, frontend, maybe design?)
- Full Stack Developer (backend, frontend, design, ???)
- Full Stack Developer (older meaning) (knowledgable about hardware and software)
- Full Stack Startup (developing, business, and everything else?. They call it a "complete, end-to-end product or service")