DEV Community

The Importance of Clean Code in Your Startup's Success

Daniel on July 31, 2022

Clean Code has become a bit of a buzzword recently, but it is important, both as a developer and as an executive or CTO in a startup. Investors wan...

Read full post

Fyodor • Jul 31 '22

I’d say that startups and clean code are not compatible at all.

Small teams => no need to share the code with many people and make it readable
Rapid development tempo => emphasis on code quantity rather than quality
Customer and investors don’t give a wink about the code quality, they just need the end product (now!) => startup founders overcommit especially on the early stages and developers need to cover the commitments and meet expectations (accumulating the technical debt)

Code quality (if it exists) is a Baby Yoda of a startup team — poor hidden child with superpowers which nobody wants to give opportunity to expose itself but everyone admires its cuteness… Only true software mandalorians are able to save it and even grow it behind the scenes. But gradually and too freaking slowly, losing motivation on the way from time to time.

Sean Allin Newell • Aug 1 '22

The only way to go fast is to go right.

Daniel • Jul 31 '22

While I do agree, from personal experience as a data enginner at BLST clean code helps me reach my deadlines better as Ispend less time trying to understand my older code. Of course, there must be a balance between qunatity and quality, but quality should not be ignored completely :D

Gabin ✨✨ • Aug 4 '22

I don't think writing clean code necessarily means moving slower. The idea is just that the code you actually write has to be easy to extend and maintain. It doesn't mean you have to go all-in and setup all the processes a billion dollar company requires. It's fine to take shortcuts but you just have to do it carefully as opposed to carelessly.

Obviously it depends on whether or not it matters that your software's users may lose their data or have a buggy experience. If you're building a proof of concept, all that doesn't matter much and you'd probably write code that goes from A to C knowing that B is broken.

Keff • Aug 1 '22

I can agree in the sense that, if it would be possible, clean code would help startups. The thing is, talking from experience after working on startups for almost 8yrs, that it's not easy to do. Time presures, fast development cycles, and not having many people on the teams makes it almost imposible to do most times. I always try to advocate for clean code, having good documentation, having time for refactors. But clients and so on don't give a crap, and just want to keep adding shit.

I would love to be able to create clean code, or just good enough code, but in my case it's not easy!

JoelBonetR 🥇 • Aug 1 '22 • Edited

It's never easy on start ups, @fyodorio and you covered the key points of software issues that start-ups face and the reasons for that, I've nothing else to add 😂

That's why we know "start-ups with strong quality codebases and culture" as Unicorns at the end.

The issue with that approach is that at the beginning the code factory speeds up to deliver a given product (call it MVP) but then they choose to follow the same for the V1 then for the V2 and as time goes on the development speed decays, devs leave, tired of not being able to work properly and iterating through the same process (develop, manual testing, PR, really quick check, merge, spot issues in QA/Prod, back to the beginning). Most of the time hurting customer's experience and the company's reputation.

That won't change without some sessions to make our customers know about that and they doing their homework on this topic (which is mostly not the case)

Keff • Aug 1 '22

Yup, that boring cycle, I can relate too well. At our startup we've been starting to move out of this cycle for a while, and it has change the mood of everyone involved... But in the end we're still doing mostly the same, it gets quite boring and makes you want to leave and do something more interesting.

We've tried involving the customers and clients at some point, but it's quite hard to make it work. If you involve the clients, everything start to go slow as hell xD

JoelBonetR 🥇 • Aug 1 '22 • Edited

So it does avoiding tests and harming code quality. The good thing is that if you involve clients they will eventually do one of two things: learn how things should be made and don't bother devs unless it's totally necessary or ignore that stuff and assume the dev times are what they need to be.

When I do freelance jobs I can afford stating "I'm not working like that. My job has a minimum quality, if you want things faster and therefore with less quality, pick another one to do the job" but I can't do that on my main job and even less in my position (TL) in where I need to balance business needs, developers needs, client needs and a large bunch of other stuff and find the middle point 😂

Keff • Aug 1 '22

learn how things should be made and don't bother devs unless it's totally necessary or ignore that stuff and assume the dev times are what they need to be.

In our case it's been the later, but we've had to put limit, protocols and define the process because they started getting out of control... And were wasting a lot of our time

but I can't do that on my main job and even less in my position (Tech Lead) so I need to balance business needs, developers needs, client needs and a large bunch of other stuff and find the middle point

Yup me too, I'm in a similar position and can relate too well xD

It's part of the job I guess, it sometimes bothers me a bit but I can't do much about it xD

JoelBonetR 🥇 • Aug 1 '22

Well if you understand the business PoV it's just a matter of explaining the concepts and let the client take the decision (either be wrong or right). It's not your business at the end...

That's OK unless you loose workforce cause this, then your bosses will need to take the decision on whether enforcing a way to work with clients or not. 🤷🏻‍♀️

Keff • Aug 1 '22

Yup that would make sense, the thing is and I've discussed this internally before with colleagues and my boss, that the company is not mine, but our boss doesn't like to get involved that much, so in most cases it's up to us to handle these kinds of things... which is not correct at all, but we have to do it. I tend to not get involved meanwhile it does not affect me or my team, but if it does I have no choice but to intervene...

I've been reconsidering looking for another job at times, but I have good benefits I won't have in other companies so it's a tough choice... But yeah, in most cases it would not be my job to do this kinds of things...

JoelBonetR 🥇 • Aug 1 '22

There's management to deal with that situations. A role in the middle like us (between development and management) should transfer information and concerns as well as the solution to them (previously analysed) but nothing else for our sanity's sake 😂

Keff • Aug 1 '22

Hahahaha that would be great, I'm starting to loose my mind a bit xD

Jon Randy 🎖️ • Jul 31 '22

Clean Code has benefits for sure, but you shouldn't be over zealous...

Preaching 'Clean Code' is Lowering the Quality of Developers

Jon Randy ・ Jun 25 ・ 3 min read

#webdev #watercooler #unpopularopinion #discuss

JoelBonetR 🥇 • Aug 1 '22 • Edited

The third tip is to use comments to explain your code. Comments are important for making your code readable and understandable. They should be used sparingly, however, as too many comments can make your code hard to read. Use comments to explain why you’re doing something, not what you’re doing

I feel in need to correct those words.
Comments for "explaining why you're doing something" is what you asked to provide at college.
IRL any other dev will understand why you did something and if not, there's a place for that: the wiki. Be that a project wiki, comments in your favourite issues tracker or whatever system you got.

Comments in code should appear at the top of each function/method and the reason is that your IDE will catch that and provide this information in different contexts where that function/method is used just by hovering the mouse over it's name.
You need to define what this function is doing, how many params it receives, of which type and what it returns clearly.
Quick example:

/**
 * Retrieves a user from the DB based on it's email
 * @param {string} email
 * @returns {User|null}
 */
const getUserByEmail = (email) => {
  return Users.find({ where: { email: email } });
}

Note that the function can return either a User Object or null, this is important to know when calling this function and without this documentation in code it may be hard for others to spot that or they'll need to dig deep into that hypothetical ORM or try it by hand. Either way it's time lost.

You can also use TS in this case which will solve this types thingy automatically, still enforcing the documentation of your code in the CI or in the Linter will help for sure on those more complex logic paths and to keep a clean code with the same style.

See this example in JS:

/**
 * Clamps a `value` between a `min` and `max` inclusive
 *
 * @param {Number} value The value to clamp between `min` and `max`
 * @param {Number} min The minimum number of the range
 * @param {Number} max The maximum number of the range
 *
 * @returns {Number} The clamped value
 */
export function clamp(value, min, max) {
  return Math.min(Math.max(min, value), max);
}

And in TS:

/**
 * Clamps a `value` between a `min` and `max` inclusive
 *
 * @param value The value to clamp between `min` and `max`
 * @param min The minimum number of the range
 * @param max The maximum number of the range
 *
 * @returns The clamped value
 */
export function clamp(value: number, min: number, max: number) {
  return Math.min(Math.max(min, value), max);
}

So it can be extrapolated to any other language (static typed or not).

Best regards

Mike Peters • Jul 1 '23 • Edited

When it comes to the success of your startup, clean code plays a crucial role. It not only enhances the efficiency and maintainability of your software but also contributes to scalability and future growth. In order to achieve clean code, it's important to follow best practices and coding standards. If you're looking for more insights into running a startup, I recommend checking out the Devoxsoftware blog. They have an article here titled "5 Core Startup Stages: An Ultimate Guide" that provides valuable information for startup owners. It's definitely worth a read!

Mikael • Aug 5 '22

"buzzword recently"
Nooo, it has been around for decades.