That’s true! But the clusterfuck is a necessary part of the product birthing process, not something to be scorned. The baby product now needs to be nurtured and educated into a functioning adult. There are plenty of opportunities here. And this is where branding yourself comes in, to get the political power you need to do something right and fun with the product. Instead of a maintenance programmer, call yourself a “scalability engineer.” If you’re in a regulatory heavy business, read the regulatory manuals and become a “compliance engineer.” It will be super helpful for your career and give you the clout you need to make the necessary product improvements as the business matures. Just my two cents. I think you’re being downvoted because your tone comes across as scornful, but it’s really a fantastic opportunity for back end devs to make a difference.
I don't think the clusterf*ck is necessary for anything. It is an indication of immature people working on something when a product goes through a phase like that. Of course, at the stage where the project is 100 lines large one does not need much structure but it can be added gradually without a noticable disruption in the flow of features supported.
The whole 'scalability engineer' and 'compliance engineer' title mumbo jumbo sounds very phoney to me. As far as the compliance part is concerned I feel inclined to make up some fake dictionary definition for it in the style of the devils dictionary for maximum cynicism. Compliance: a lot of paperwork that asserts that a set of desirable attributes apply to the mirage that management has dreamt up about a project. The mirage may or may not be in any way related to the actual state of said project.
Your cynicism about compliance is misplaced IMO. Compliance is about making sure the product covers things that are boring but important, like security, privacy, and accessibility. These are things that the pioneers blithely ignore so they can ship something. But if they continue to be ignored, there are real, sometimes disastrous, consequences (even if the disaster is just for one person, e.g. an otherwise well-qualified blind person losing their job because an app they're required to use is inaccessible).
That’s a fair and reasonable perspective. I’m curious if you’ve worked on such a product that had a baked-in level of maturity from the start? I never have. I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck!
Scalability engineer and compliance engineer very much are phony mumbo jumbo from the perspective of a software engineer. However from the business perspective they are very real and I think they are helpful to communicate one’s own level of maturity and ability for the business owners to trust you to get things done for them. It’s about communication and signaling more than the reality of what you do.
I have seen the startup stages of software projects with varying levels of quality. The whole spectrum from very bad to very good can be observed and/or participated in in the wild. The good ones start out with one experienced developer. After two or three features have been added (within two weeks to a month) more developers, possibly less experienced ones can be added. Their number should grow somewhat slowly mainly to make sure that they are not getting in each others way too much. Practices that make this work are automated testing and code review. Occasionally, some pair programming can be practiced, especially when some refactoring is needed. I am talking about limited refactoring here, maybe taking two to three days. If the project can be split in a front end and a back end one may start out with two developers. In theory a system that consists of N services might start with N developers but if N starts out larger than 3 one is quite likely engaging in over engineering.
I agree with cjfd; it's a false dichotomy. "Either we put zero effort into making this code maintainable, or we won't move fast enough."
> I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck!
I'm personally working on a v1, and (you'll have to take my word for it) it is far from that.
We are making conscious decisions: "here's a guess about the future that we're confident about, so we're willing to add in more structure/abstraction here," or, "We're not sure about the future of this feature set; let's be clean but minimal about it."
Also, co-workers have raved about our work on this project, including speed. So that's further evidence that it's a false dichotomy.
At least you have something. I had to come to respect this.
The code may have been bad, thrown together, and not architected correctly, but, if the company was able to get customers and become profitable enough or get funding to hire people to clean it up, they were a success.
The Twitter codebase was a well known clusterfuck, but they got product market fit and were able to survive long enough and become capitalized well enough to rearchitect their system.
This is key, regardless of whether you think that "doing it right the first time" would have not taken meaningfully longer, and paid off in the long run over and over.
For any meaningful product, you want to get customer feedback early and often, and you want to do it before your competitors get a chance to.
I say this as a more stereotypically "Process" person/developer than a "Pioneer". I know too many failure scenarios. I overthink. I get into analysis paralysis when there is an open page. I need that Pioneer to help my company and my team get started.
But give me an existing system, and I'll mold it and expand it as quickly as that 10x Pioneer.
I love taking shipped hacked together code, and gradually refactoring it and improving it for 10x, 100x scalability of both system throughput and development team growth.
The important factor here is shipped. In production, with customers. Customers who already see the value and benefit, and don't mind the occasional blips and glitches that will take much longer to fix (and probably require massive rewrites) to fix behind the scenes.
Beautiful code without users is worse than nothing at all.
I like to think of it as - pioneers build the base enough to prove some part of product, market, or technology so there is later revenue for the engineers to have a job. I've heard tons of engineers teams whine about technical debt - without realizing that there would be no company to employ them.
Pioneers tend to be good at many domains; engineers tend to be great at one or a subset of domains. Specialists refine the toolsets and methodologies, while pioneers main goal is to just help prove business value.
What about in the case where it's already known that there is a product-market fit?
When Pioneers leave an absolute mess in their wake, changes to the project take more and
more time. There is a trade-off, and the "immature pioneer" mindset (working with no thought for the future maintenance of the code) can make the scaling / maturing process of a product needlessly painful and slow.
Maintenance is not a “problem” even if I am the maintainer or in my case, the “rearchiterer”. It’s what they are paying me to do. What a company needs at one phase of its existence is different than at another phase.
It would be just as wrong for me to come into a company at the beginning of its existence when they are just trying to go from 0 to MVP and worry about unit tests, branching strategy, and “process” as it would be to promote the pioneer to a team lead.
Interesting analogy, and I would agree if the developer is intentionally concealing their actions to escape consequences.
However, the situation is more often someone inexperienced doing a bad job, or someone experienced doing a bad job because they're crushed by unrealistic deadlines, or someone cutting corners intentionally because the company is in a do-or-die situation. None of these are immoral, but result in the same outcome.
