Preface, TL;DR
-------
This question is about the implied tradeoff between the speed of development and the quality of code.
I am **looking for methodologies** which can be followed in order **to optimize development speed**, even **at the expense of code-quality** and the accumulation of technical debt.
I am *not* looking for ways of communicating the importance of code quality to those in charge. Please assume everyone understands the importance, but have chosen to optimize for speed of development and that they are correct in that decision.
I have learned a lot about how to optimize for quality, but nothing about optimizing for speed of development, and am looking for references.
My personal experience taught me quick and clean go together, which is not what I see around me, making me believe I am missing something very fundamental.
___
Code in real life isn't good
----------------------------
I keep encountering code during my work that is less than optimal.
By that I don't mean simple improvements could be made, I mean:
- Lack of encapsulation ("what" mixed with "how" on several levels)
- Multitude of duplicated conditionals over different modules
- Under-abstraction
- Wrong naming
- Lack of tests
- Any other poison you can come up with
This is way beyond things that a short refactoring session can remedy.
I see this over and over across many software engineers, across several seniority levels, and across several (startup) companies.
When talking to colleagues outside the office about it, the vibe is "The code is always bad. You have to learn to deal with it" (which I am trying to do now). When talking gently with colleagues from the office, they are either not aware of the problems (mostly juniors or non software majors), or they excuse it by "we had to get it done fast".
I am beginning to believe that if so many seniors claim they optimized development speed at the expense of code quality, they have some secret method of getting it done, repeatedly, which I somehow miss. Otherwise, how did it get to be like this?
I believe this is code in real life. I read a lot about good code. For example, [The Gang of Four][1], [Clean Code][2][non affiliate link], [lectures][3], and [SOLID][4].
I observe that these practices are considered by many as nice to have, but are not followed in practice, especially when under the pressure of business, or if people don't code as a passion, and don't extend their knowledge or notice patterns by other skilled programmers.
This tendency of code not being perfect will probably be amplified on my own career path, which is leaning toward algorithm development, and away from pure software engineering.
___
What do I do today?
----------------
When I write code "**from zero**", it is very easy for me to implement the good-code principles, and I tend to be faster as I write good code.
I tend to follow my own code much better, thinking less and typing more, having fewer bugs, and able to then being able to explain to myself and others what's going on, when it is organized. I feel this makes me faster, as most of the time coding goes for thinking, and writing tests, which good code minimizes, and encapsulates.
When handling **existing, good** code, there is a slight learning curve, but then I can treat it quite easily, and not worry that I might break things. I can be quite sure I am on the road to being done and explain what's going on and estimate how long it will take.
When handling **existing bad** code, I tend to:
- Not know what I am going to break with my changes.
- Not know how code is structured and have to read the whole thing prior to writing, which is virtually impossible due to wrong naming and no encapsulation, no external documentation, and generally asking people results in "oh, yeah, there's also that case" if they are still even around.
- Start to build encapsulations myself, just to know that when I'm done, I am really done, and that I didn't break anything. Also this allows me to not break my own changes elsewhere.
- This is a *really* slow process, relative to the person who wrote the code, who knows by heart all the pitfalls in the code.
- This is much slower than the boss expects.
- I usually can't give a time estimate for my work prior to going into such code. Many times, I only find out about the code quality after having spent some time in it.
When being asked to code "quick and dirty", I have no idea what to do in practice. I can code quick and clean from zero or slow and clean.
**I want a tool in my arsenal, to be able to code quick at the expense of dirty, to be able to choose when to use it.**
___
This topic seems clear to everyone, but no one actually talks about it.
------------------------------------------------------------------------
Bosses and colleagues, mostly at startups, all say once in a while "quick and dirty" or "do it faster; we will repay the technical debt later", or "just get it done; deal with it later".
I never hear people talk **technically** or **methodically** about how, in practice, to favor quick and dirty over clean and slow. As I view it, quick and clean go together when "actually working code" is implied.
How can I get all three done together, in new code, and in existing code?
1. Deliver **faster than when writing clean code** (implied doing something dirty)
2. Writing working, tested, explainable code (sleeping well, not worrying production servers just broke because of me)
3. Working regular hours
I understand how to write good code. I want to find out about methodologies of being faster at the expense of quality.
I am looking for methodology, rules of thumb, and book or lecture references.
[1]: https://en.wikipedia.org/wiki/Design_Patterns
[2]: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
[3]: https://www.youtube.com/watch?v=ZsHMHukIlJY
[4]: https://en.wikipedia.org/wiki/SOLID