I work in a small company that has all the things the author mentioned and that can work quickly as a result. Almost none of it comes from "we'll do it this way", almost all has evolved over time as we've been able to gradually introduce more rigour to our development process. Much is down to some great engineers at the beginning setting us on that path.
Furthermore, you absolutely do need to cut corners _somewhere_, but a seasoned team understands that taking on such tech debt will require a reduction in velocity at some point in the near future. It is then incumbent upon engineers to ensure management understands that the team is borrowing from future velocity to deliver quicker, and it's incumbent on management to facilitate remedying that tech debt at the earliest available convenience. If management does not facilitate removing tech debt by allowing for such refactoring/structural work it is then incumbent on engineering to stop offering the shortcuts that temporarily increase velocity, because there's already too much tech debt to be had, and to take on more will reduce velocity unacceptably.
A good startup has experienced engineers and experienced managers who understand this dynamic.
For instance I think type/schema debt (where your domain model has changed from your original type/schema debt) is very painful and has a very high interest rate.
I think duplicate domain logic has a medium to high interest rate.
I think code organization(what methods go where) has a low to medium interest rate.
I think white spacing, duplicate non-domain logic and code style has a low interest rate.
A gentler, more helpful admonition would be "find the theme, reuse the theme". If you only set out to compress the code you obscure the theme of the code, but if you set out to elevate the theme as you find it, you are likely to let more code rest in a form that is duplicated but a reasonable reflection of the themes currently present.
To GP: schema debt is usually from adding stuff before you need it... it's almost always pre-mature and one should have a good migration strategy in place early on in order to support destructive (or at least not-simple) restructuring over time.
One of the very most frustrating things for an exec is downtime. The next worst is inaccurate time estimates for IT work. If you don't have at least some experienced architects/developers, it's normal to find yourself in the position where nobody knows what they don't know, and that's a bad look for everyone involved. It's also why a lot of bigco's have been outsourcing internal appdev to MSPs over the last 10+ years. It de-risks projects, eliminates skilled labor shortages, and ensures reasonable QoS... in theory. It doesn't always work out that way, but that's the objective.
I feel like it always comes down to a communication issue. Team members need to feel heard, and feel acknowledged that you fully understood what they are suggesting. On the other hand they need to understand that there are constraints that force a decision that might not technically be the best, but is pareto optimal. When this discussion occurs I sometimes bring up the analogy of these space movies where they put everything on a table that the astronauts have up there and try to make something out of it that mostly consists of duct-tape. Sure there are better tools, but the stuff on the table is all we have. Another thing that took me very long to understand as a developer is that innovation is a risk that might not always make sense economically. A thing that took me long to understand as a manager is that the happiness of your devs is one of your most precious resources that you have to manage well.
So I use the idea of a novelty budget to negotiate with my engineers. "What things do you really want to change? Let's focus on that, and use tried and true, albeit suboptimal, methods for the other stuff, to stay within our novelty budget." Down the road, once you can handle more risk, you can introduce one of those changes that were originally punted.
"Novelty Budget"
So, short-term, you have happy leaders who see releases as they want, and unhappy devs who are in a shitshow of code.
Long-term, if your startup is either acquired or starts to grow a strong revenue stream, leaders need to appease their new owners or their influx of new customers, and you can’t slow down because either a.) the new board needs to be impressed to justify their large acqui-investment, or b.) your new customer base is too big to risk losing. So you keep building on bad code, maybe squeezing in a few skunkwork refactored that only the dev peer reviewing and QA know about, and accept any delay on release as the result.
The approach should be somewhere in between, ideally with the engineering team being empowered to tell leadership “yo, we have a bomb of bugs just waiting to burst if we add one more feature with duct tape, let’s prioritize time to address it”.
If leadership doesn’t trust your team, then you have bad leadership.
Don't have the runway for that? Are you managing the startup as well as you could? Why did you tell your investors that you could do it in five months of dev time?
Source: I'm a trained sailor.
Engineers below the upper senior levels typically operate with an "infinite" mindset in making these choices. We all laugh at the relevant XKCD[0] because there's a grain of truth in there. This isn't a knock on engineering, it's just the nature of operating at the lowest levels. You become involved in the problem and you solve for local maxima.
Leadership done well is going to offering transparency to the people on the ground level, communicating timelines and strategy in a way that is relevant to the problem at hand, so people know, for example, how long they can spend solving a particular problem.
Where this sometimes goes wrong is, the higher you go in leadership, the lesser certainty there is. There are no "right" answers, there isn't perfect information, and yet, decisions must be made. If engineering is operating on different base assumptions, those decisions will look wrong (and they might be). And yet, someone needs to get people aligned and moving forward, because moving fast in the wrong direction is typically better than moving too slow, even in the right direction.
Except in my experience it’s not two years, it’s two months. And I can set up two micro instances with terraform in less than an hour.
So soon you’re burning your three months of runway with development at 20-50% efficiency, and have no ability to pivot, if needed, because your infrastructure is rigid and hardcoded.
Neither scenario is “correct”, there is only “judgement”, and it can be devastatingly incorrect either way.
A lot of people with strong or extreme opinions (too little or too much tech debt) are inadvertently being fooled by “personal survivor bias“.
The post was more of a metaphor than a concrete example.
However, as a manager I can’t count how many times my team has declared that they can do something in under a day only to have it become a part-time job for someone to maintain indefinitely, or a multi-week rabbit hole as they debug some unexpected behavior, or technical debt as they neglect to document their solution, or a productivity bottleneck as everyone else must now either learn Terraform or wait for the Terraform guy to be available to help and so on.
When I transitioned from IC engineer to engineering manager, I quickly learned that engineers frequently assume the best-case scenario for their time estimates, while managers end up planning for the worst-case scenario. The catch is that it’s difficult to tell an engineer that their time estimate could be an order of magnitude or more short of a realistic estimate without implicitly insulting their abilities in the process. ICs also quickly forget that many of us managers were once over-optimistic IC engineers as well.
To be fair, bad managers (and there are a lot of them out there) often get really angry if you give a reasonable worst case scenario time estimate for a task, even if you can back it up.
I've constantly been on projects where someone said, "This will only be a month of work for maybe 3 engineers." That project quickly becomes 5 engineers over a year because of empty promises.
That said, some of these projects frequently time a very long time because there's dishonesty in time estimates. If they were honest with estimates, you wouldn't have to cut corners. They try to cut corners to push a project through quickly - but it backfires constantly... Which leads to more work rather than doing the more effective and reliable part of lots of non-visible work before seeing visible results.
But when you 1) don't have an constructive relationship between CIO/CTO and business leaders, and 2) offshore everything not to follow-the-sun but purely to save money (and then pay bottom of the barrel even in lower cost regions -- that company still only pays engineers 10-12 lakh in south India), you're going to get an inefficient org creating crap quality software.
> the senior engineers knew our estimates were crazy high compared to what they'd be able to do independently
Interestingly, I worked at a company where teams of engineers were given wide latitude to design, implement, and deliver their features in isolation. The theory was that engineers could be more productive if they were left alone to make the decisions.
I'd say it worked about 1 in 4 times. The other 3 out of 4 times, engineers created their own labyrinth of over-engineering, spent too much time building things as reusable frameworks instead of simply getting the job done, and over complicating the system with unnecessary "Wouldn't be cool if..." type features.
This had the benefits of ignoring the usual variations of software planning. Any development task could take 1 week or 4 weeks (if it goes well or not). This stops being an issue when the planning is quarterly because few weeks of jitter doesn't matter.
The question is then, do we have time to do this task next quarter, as well as the other 3 tasks we scheduled there? otherwise we'll plan it for the quarter afterward.
I (engineer) have experienced exactly the opposite. On Thursday I say "It will most likely take me a week; I cannot possibly have it done in less than three days; if X is true -- which I can't know yet -- it will be more like two weeks". And that becomes a commitment to have the code on master by next Wednesday.
Perhaps I've just been unfortunate, but most of the time when I have given qualified or worst-case scenarios, I have been pressed to assume the best, and that's what gets written down.
Very few people involved understand how difficult it is to estimate work for some/most projects. If you haven't explored the problem space pretty well, you can and will run into problems that are unique and very troublesome. And you can't know that ahead of time, except in a very hand-wavy way.
Fucking that. Only skip the basics entirely if you don't plan to hire anyone in those 5 months (no or inadequate tests, no scripted way to create a dev instance? You just cut their first-two-months productivity in half.) and are 1000% sure no-one's gonna horrifically break prod, and don't mind dev velocity dropping ~10% (and/or bug rate and "of shit it's on fire" calls increasing alarmingly) every month over the next 6 months.
There's a lot of room between "we need a k8s cluster with autoscaling, three kinds of databases, lambdas, blah blah" and "LOL develop on prod YOLO!" IME this kind of thing never gets added in month 4 because there's already too much tech debt. Add it in month 1. A couple days and 10s of dollars/month setting up or buying tools & services to keep your team confidently moving fast over the next half-year is some of the most valuable work you'll do.
[EDIT] oh and in the specific case of Infra as Code or fully-scripted deployments, around month 4 when your stuff's a bit more complicated it makes your answer "yeah, give me these couple pieces of info and put me in touch with one of their tech guys and I'll have it done by lunch tomorrow" instead of "uhhhh... fuck... uh.... two weeks? Hopefully?" when your sales guy says "we've got a huge deal almost closed but they need our thing hosted on govcloud/on-prem/European servers, can we do that?"
It also made me think of the Apollo 13 movie.
The engineering/process people got the thing into space, the adaptable/dynamic solve it with 'gaffer-tape and whatever is laying around' people got the thing home.
We still need both approaches for different reasons.
“Personal survivor bias“ accidentally chooses a side for you.
Experience eventually makes one realise there aren't diametrically opposing sides, just different capabilities needed in different circumstances.
And then there's modern world of slapping together libraries that are often not known, sometimes with closed source, sometimes without real documentation. I've had to use disassembler in the past to access framework we were supposed to use...
If I don't know something, I simply say I don't know. And if I do, I always position the trade off of the choice relatively and weigh it.
If you or some other senior engineer knows X, then perhaps they can implement X in an hour and things remain simple.
If your team does not know X, then it will take a week to learn X, understand it, try it out on a toy project and implement it in production (which alone might make it an overkill, because it's not worth a week) and it becomes quite plausible that we'll implement it wrong in a way that will bite us later.
So unless the benefit is huge, then it's quite reasonable to say "x is overkill" for your team simply because you don't know X.
> Me as a manager at a startup: "Do not install Terraform. Finish the import prototype... now."
The team knows Terraform. The manager probably does not. I was responding to that.
I've seen companies that have no funding issues building products that they know they will need to maintain in coming years and still follow a few or none of the best practices.
But I've also seen people building SW that no one can guarantee that will ever be used (and gets scrapped after a few months) spending days and weeks setting up the perfect agile CICD setup and arguing in endless pedantic discussions in code reviews.
but I'm sorry you can't deploy without CI/CD unless it's like a desktop or mobile app or something. You don't skip that for servers. Does it have to be perfect? Hell no, but it needs to be in place before you can seriously call it shipping
But indeed, especially on mobile where you need to have releases go through external validation, CI/CD can save you a lot of time.
You are absolutely right, that was wrong. They should have instead ignored you and install Terraform.
1) Having 5 months of runway is an existential problem that your CEO's fundraising should have addressed 7-12 months ago
2) Lacking a proper code review process ensures that you'll pay pounds of prevention long term instead of ounces of prevention, which over the long term is not a frugal usage of your already scarce engineering resources
3) Your senior engineers should be having the conversation with your junior engineers about the tradeoffs of heavier vs lighter forms of code review and CI process. Unless...
4) You hired a junior engineer as your early or first employee without a senior engineer and are unwilling to do the necessary work mentoring them yourself
You are responsible for each of these failure modes. Who made the decisions to get the company to a place where it only has 5 months left of cash? Who made the decision as a startup manager to let other managers take it there? Who made the choice to hire the junior engineer? Who made the decision to forgo proper code review standards?
It sounds like your junior engineer has a sense that they are on a sinking ship. Maybe they're right. You're one of the captains. Turn it around, or cut your losses and learn from your mistakes. Saying this as someone who has been a startup manager, I think it is a profound breach of the duty of leadership to not do so, which is what it sounds like you are doing right now.
EDIT: In case you need some pointers or some food for thought, I think that another HN thread that's also on the front page could be a great place to start:
Remember that management is not the same as IC work at a higher seniority. It is a fundamentally different vocation. You really need to internalize that to be effective and it is tricky.
Years worth of runway is not the norm. Having your choice of senior engineers to hire right away is not the norm. Most startups exist as sinking ships.
It sounds like you lucked in to a company that raised a shitload early on and so had the luxury to make these decisions.
I worked for a string of them early on in my career. I was miserable and worried that I'd never get anywhere better because of the scarlet letter of working at a failed company (and several of them) would be my first impression. Rather than blaming it on luck, I resolved to figure out where I went wrong and how I could avoid it in the future.
While you cannot remove the element of timing and large scale market events outside of your control, startups are about making (and learning to make) calculated risks. Mediocre startup operators love this kind of argument (so and so can do things because they raised more money than us because they're lucky not because they executed better) because it lets them escape the consequences of their own unforced errors and ineffective execution. You won't hear this argument from effective operators because it would get laughed out of the room. They know that they have to operate proactively, not reactively from (and even before) their first fundraising event.
The most well run companies have a tendency to create exponentially more, not less, expansion and subsequent job opportunities. My advice is don't work for a risky early stage company until you learn what success looks like somewhere bigger. At an early stage startup that's on the right track, you'll see a lot of the same things just in a smaller org. But it's hard to know what you should require unless you've at least seen what it looks like to work at a well oiled machine. Folks that tell you otherwise are either ignorant or willfully trying to pull the wool over your eyes.
Counterpoint #2: Amazon's code base was a monolith and highly dependent on Oracle. The rest is history.
The order of priority is to have a product that customers want, convince investors to give you more money to continue your growth and improve your infrastructure and hopefully become profitable or at least have an exit strategy.
Git didn't exist, SVN didn't exist before 2000. Common languages in use today didn't exist or were in their first versions (go, python, java, etc...). Most of the unit testing frameworks and IDE that are taken from granted weren't invented yet.
There were different expectations back then. No software company should be running in 2020 with no version control, no unit test and no CI.
Java was very big in the Enterprise by 2005 and yes there were plenty of IDEs back in 1995. Amazon I believe was originally built on a C code base.
There are plenty of companies that have no automated unit tests and do quite well with manual testing.
But we aren’t just talking about source control and unit testing we are talking about code quality.
Code quality is limited to the tools available at the time. It was an uphill battle to preach for (automated) scripted builds or any form of (automated) testing without having the later tools/frameworks/infrastructure at disposal.
Funfact: The java compiler was still fixing "bugs" in 2016 to be able to produce an identical JAR between builds.
Nowadays if an intern opens PyCharm. He can get right away a lint report on the current file and entire codebase, finding potential bugs and questioning why is this thing not running automatically on commit. This pushes quality up organically quite a bit. By comparison doing embedded C++ development in the 2000's, I can only recall of one company having a static code analyzer, that costed no less than $50k for a handful of small projects (they charged by line).
C is not a new language. People have been writing large well structured C code for decades. The first C linter was written in 1978. Even PC-Lint was written for C in 1985.
But you're totally right that this is not the junior dev's problem!
I think we're making the same point, but I don't disagree. I think this is what I'm getting at. A CEO who cannot raise and is at 5 months of cash left has a) effectively gotten a vote of no confidence from their existing investor base, or b) they are not asking because then they are delaying the inevitable and eventually impossible to ignore conclusion a). Not being able to avoid low cashflow despite your best efforts is a failing on the CEO's role. The CEO is the last line of defense in terms of responsibility, and fundraising is supposed to be one of their core competencies and responsibilities. It's why the job is not for everyone.
Once you're established, growing, and accumulating features it will take weeks/months. (And if you need a duplicate environment for staging, how many clicks will it take?)
Generally for most resources, I feel like I can write terraform just as fast as I could create the resources in the console.
Probably not a good example, but I agree with the sentiment that you have to prioritize the business.
The (appropriate) question was “We have 5 months of runway, does this make sense?”
Assuming the manager is halfway competent in listening to their team, then this should be a useful focusing activity for both the dev and the manager.
In business, and in life, it isn’t about what you “can” do, it is more about focusing on the handful of things that give you the biggest “bang” for the buck. Think Pareto law, and how you can get 80% of a result, for 20% if the effort.
So, in the context of the scenario, the developer should be asking themselves: 1. What problem does <insert tool/process> solve now or will solve in next 5 months? 2. How painful is the problem, and what is it’s frequency (High impact, but low probability; moderate impact, but high probability).
3. What is the cost of the new process/tool to the team? (Time, cognitive load, $$$ that could be spent elsewhere).
As long as ratio of value to cost is large (10X or more), in the timeframe that matters (in this example 5 months, for most companies time is measured in years), and you can articulate it, selling the idea should be a no brainer.
However unless you can truly get that 10X(or more) return, then it might be better to focus your improvement activities elsewhere.
All that said, I do think the “Command voice” at the end is a bit of an issue... at least for me. You are “pulling rank”. This is “okay” if you have built up the “rep”/karma/trust to do so, but unless you have, will likely make the dev (long term) run for the hills. It might take a bit more time/coaching to explain something like the above to them, but that is an investment in people that lasts a lifetime, whether or not the startup lasts past 5 months.
Prototypes have no restrictions that we would normally place on code (coverage %, automated pipelines, etc) and can only be created in a sandbox AWS account that has no access to our internal systems. It allows developers to prove out concepts or work with product to quickly iterate on PoC.
On the other side, PoC's have a limited lifespan and if successful, are expected to be re-implemented as an MVP, following our internal standards and guidelines.
I like the separation of AWS accounts.
The problem is that most companies can't do prototyping because they don't have the resources. They build a prototype, and then they don't throw it away and build the proper version and they use as production.
There are so many things in production that are prototypes (even when people/companies cannot allow themselves to recognize them as such...), having a word for this pattern is great.
"It's just simple project, don't bring out the big guns".
Somehow, a simple requirement of "make sure we can backup it all and load it elsewhere, manually, nothing fancy" made it so that I lost 5 days purely due to acceptance of manual work at the start.
Often, creating things using proper automation tools ends up being significantly faster than doing things manually, and the result is better.
If I'm setting up a proof-of-concept, I'll at the very least try to write a shell script that contains whatever it is I did to get a host set up.
If doing stuff for production, I might have one instance where I set up things manually while simultaneously writing the appropriate automation to get another instance up and running. That allows me to iterate the set-up quickly while allowing me to verify the result by recreating it from scratch using the automation I made.
Big companies typically have fewer constraints on time, money, and developers. They can have very mature development processes because of that.
Small companies typically have tighter constraints. It's not as if this hypothetical manager doesn't want better process, but if the things to spend time on are "better deployment methods" or "ship this feature in time to land a critical contract," there's no choice there.
OP has, potentially, a unique position here. If they can find a way to use their experience to help implement small process changes without grinding development to a halt, they can seriously improve their team and maybe emerge as a leader as well.
This is different from "we need to stop and do all-team code reviews before every PR merge!" The time may not be there, and the management buy-in sure isn't.
But encouraging teammates to add new tests with each new feature, and helping folks who may not know how to do that, can have a huge impact. Taking an hour or so Friday afternoon to gather the team and casually review merged PRs or do a sprint post meeting over drinks can be a good unwinding activity.
OP's got an opportunity here.
They key here is to find problems with the current environment that can be tracked. Downtime, performance, bugs in prod, etc... If you can't find any measurable issues that management can relate to, then quite frankly, there isn't really any reason for management to invest in solutions to problems that don't exist.
Not to open the test-driven development can of worms, either, which seems to be part of the OP's dispiritment ... but I've yet to see any scenario where TDD was not a massive waste of time.
"Can't fail your TDD tests..."
taps forehead
"If there's no code to test"
(sidenote: It's possible to do kind-of TDD with exploratory code in certain environments - essentially, you start writing code from top to bottom and fill in missing bits using debugger all the time)
It can work good as a built in driver to exercise the code you are trying to write as you go. It also gives you a chance to test the interfaces to the code you are making as you go for usability, because you are coding to it.
There are actually some really interesting videos demonstrating the RED/GREEN/REFACTOR cycle they propose.
It doesn't help that often, even otherwise good material about TDD, didn't really talk about cases like exploratory coding - working from messing around in a REPL, formalizing the code into TDD skeletons, is pretty powerful method, but isn't (wasn't?) mentioned often when I learnt the most about TDD (granted, that was 2005-2015)
As your basically exercising the API through the tests, your seeing how nice it is use.
Likely would have been a single day project to have everything inside of Terraform.
I work for a company that took all sorts of shortcuts that we are digging our way out of now. But guess what? If they hadn't taken those shortcuts, they would have run out of money before they found product market fit, would not have referenceable customers (B2B), would not have been able to secure funding and the company wouldn't be around today and well enough capitalized for them to pay me to help improve processes.
Not using prod DBs for development is common sense and best practice.
Not pushing to prod is common sense and best practice.
Same thing about breaking tests, spaghetti code without review.
It's not some pie in the sky, engineer-wants-to-tinker-with-shiny-toys like using Terraform or Kubernetes would be if you only have 10 paying users and two microservices.
If you happen to know the runway time you got before things start to fall apart economically, I don't think there's much to argue regarding code quality (and general maintenance of the platform).
In large companies, projects usually have a budget and some desired launch date. If that launch date is not met, your _worst_ case scenario is you're fired. While your best is the acceptance that It just got delayed by whatever factor affected the outcome.
With small companies, your worst case is you're fired and the company could go bankrupt (or something as bad).
Now, OP said he was at a mid-size company and I'd like to believe he could be a beacon of change as the company grows. Maybe all the other seniors were used to work in startups and just can't fathom doing development any other way.
Bottom line is, your expectations might be off depending on the scale of the company and their current objective.
OP was talking about code reviews and testing. He did mention infra as code but not TF specifically. He didn’t say it was a startup with 5 months runway (aka a soon to be dead company?)
TF is like Typescript: if you already know it why not use it? If you have to learn it on the job at a high pressure startup then maybe not. Not clear he is working at a startup or just a regular old company
You as a manager at a slightly more mature startup: "What, you want to rewrite? No, everyone knows rewrites don't work! Just hire up and keep moving fast."
Experienced eng lead after a few months of burning out on a miserable project: "I have better options for this, here is my resignation."
Board member after another few years and lots of turnover: "It seems like we're no longer able to execute because of all our technical debt. You have been a great manager for this early stage of the company, but now we need to bring in the mature company professionals. Thank you for your service."
end scene
I do not even claim that this is a bad outcome. It really is important to execute quickly early if you are going to have any chance of success. I have made the mistake of being too slow too early. But path dependency is also a big deal, and there is rarely (never?) an obvious bright line point at which it is clear that the time is right to up the professionalism game. It is not hard to get into a situation where the team is spending nearly all their time baling water out of a sinking ship that you're still trying to sail while competitors speed past you in newer sleeker dryer ships. I also think the hiring / turnover risk is a real problem. There are companies with good engineering practices, which make work much more pleasurable, and you are competing against them for talent.
But I think this is a false dichotomy. I think there are a set of practices that don't introduce so much friction that they are an existential threat early on, but that are small steps in the right direction down the path to practices that scale well.
I think it is telling that you went straight to Terraform in your example, although nothing like that was alluded to in the OP. I would agree with you that Terraform does not belong in this low-friction-step-in-the-right-direction category of practices. But I think all or most of the practices the OP actually listed do fall into that category. Code review, in conjunction with automatic style fixing (which most languages have tools for now), is low friction and has immediate value. Same thing for unit tests. I do think a whole end-to-end testing setup is beginning to be more friction than can be afforded, but unit tests are easy (especially if you choose languages with type systems that allow you to dispense with tests that verify the type contracts are being satisfied). Automated deployment is actually both a step in the right direction and something it would slow down your early execution to not have.
There is a huge gray area, and I think it is really difficult to strike the right balance (to wit: I've never seen or personally accomplished this balance satisfactorily), but I think it is the right way of framing it. I think the right mindset for you as a manager at an early startup is not "we don't have time for that!" but "will the ROI of that be worth the time?", and that you need to do the hard work to explain that that thinking to and get buy-in from your developers.
As a manager, one of the your tasks are to make sure that your team knows why they are doing what they do. That way, when there is no time for lengthy discussions, they don't feel demoralized when you give them an order they disagree with.
Another task is, to make sure to get the best out of your team. That means to use the experience and knowledge of people as much as possible. Not doing that only drives down motivation.
What happened to me in the past, in a different domain, was somewhat similar to OP. I was explicietly hired because of my FANG background to imporve operations of a new business unit for a German unicorn. So that's what I started to do. Map processes, talk to the team, shadow them, identify issues and problems, work out KPIs and SOPs... the drill. Ony to be shit down by my manager at every turn "because we have 1,000s of proplems right now and nne are addressed by what you are doing". That sucked, it really did. My impression was, that they wanted FANG level withut putting the effort in. Just having someone with the right experience doesn't magicaly solve your problems.
In the above example, when time is critical, implement it. But hen have an pen discussion with your team about best practices, and maybe use whatever solution your "bi-corp" people have in mind.
The tradeoffs are not obvious. It could be that terraform is as important to this startup as version control would be, they just don’t know it. But if it ain’t broke....
Btw, I’ve worked at a startup (25 years ago) that had no version control and I was the one who identified the problem and introduced it. I also was unaware we needed it or what it could do for us before we had our first pucker-up moment with the source code. After version control we moved faster and slept better. Or we would have if we weren’t pulling all nighters.
The startup failed anyway.
What exactly do you mean?
Two micro instances don't seem to warrant using Terraform
It is (eventually, once you learn it) faster and more intuitive than bothering with the AWS console, and I often reference Terraform's own AWS resource documentation over the AWS docs since it usually has better information density.
Anyway, the issue is all beside the point, I think we realize that Terraform was used as a placeholder example. Another example might be setting up single sign on, Active Directory, and other things that are truly not necessary for a company of that scale.
The other part of this that if you've got a startup with 5 month runway and 10 employees, hiring an Infrastructure as Code SME is probably not the best use of your dollars. Sure, I was able to put this side project in Terraform in under a day, but I also can't write a front-end application to get myself out of a wet paper bag.
It's a good idea to start early with IaC but one of the marks of a good engineer is knowing what tooling to use for each circumstance.
Your app might be a perfect fit for Terraform or it might not, I couldn't possibly comment. Given the info you've provided it seems excessive but it's hard to say for sure
Agree, if you're introducing it to a new team and don't have time to teach the tooling that could be problematic.
But being somewhat familiar with Terraform I would use it to launch a single EC2 instance. Because it's about as fast to do that as it would be for me to use the AWS Console.
It's not that I think Terraform is needed for that small of a project, it's that it adds no cost even for tiny projects.
You are right that size is not the best measure of suitability.
I would make the case that, even with 5 months of runway, you should invest in a solid foundation. Because if the company goes down, it does. Only a little bit earlier. if it doesn't, which is I assume the reasoning behind the company in the first place, getting the basics right now has a huge impact on runway and scalability later on.
That doesn't really make sense, it's not like there's some huge fixed cost of using Terraform, the whole point of infrastructure as code is that all the infrastructure is code, i.e. it's all variable cost.
Small infrastructure as small code.
And then it's all there when you expand. Change `num_micro_instances = 2` to `4`. `10`.
Young dev from large corp: "Yes. But if you don't use Terraform we wont be able to see our infrastructure changes over time. We don't even have a proper code review process."
Me as a manager at a startup: "We have two micro instances. Do not install Terraform. Finish the import prototype... now."
Young dev from large corp: "Sigh, ok, just saying in 2 years from now we wont be in a good spot". [Then proceeds to blow 2 hours complaining on hacker news.]