Daniel

Posted on Jul 31, 2022

The Importance of Clean Code in Your Startup's Success

#beginners #productivity #computerscience #programming

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 want to see that your startup is run efficiently and that you have a good understanding of your code base. If your code is clean, it will be easier for them to understand what your startup does and how it works.

This can give them the confidence they need to invest in your company. As a developer, and from my own experience, writing clean code, especially in a startup where new ideas are tried every week, keeping your code clean will help you when you inevetiablly have to go back and reduce your tech debt or just fix some things.
Customers want to know that their data is safe and that your product is reliable. If they see that your code is wellorganized and easy to read, they’ll be more likely to trust your product. Additionally, if you have clean code, it’ll be easier for you to make changes and add features down the line.

Partners want to work with startups that are organized and have a good understanding of their technology. If your startup has clean code, it will be easier for potential partners to assess your technical capabilities and decide if working with you makes sense for their business.
clean code is crucial for the success of any startup. By investing in clean code from the start, you’ll save yourself time and money in the long run while making your startup more attractive to potential investors, customers, and partners.

How to write clean code

The first step to writing clean code is to keep it simple. This means using clear and concise variable and function names. It also means avoiding unnecessary complexity. The goal is to make your code as easy to read and understand as possible.
The second tip is to avoid repeating yourself (DRY). This means not duplicating code unnecessarily. Duplicated code is more difficult to maintain and can lead to errors. If you need to use the same piece of code in multiple places, create a function or class for it. This will make your code more DRY and easier to maintain.
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.

The importance of clean code in your startup's success

Startups should aim to keep their cyclomatic complexity low, as this will save them time and money in the long run. There are a number of ways to do this, such as using comments and clear variable names. In addition, startups should use coding conventions and style guides to ensure that their code is consistent and easy to read.

A personal tip

Never assume someone will understand a clever solution, not even yourself in a month from now, always document your snippets with a few words like mention before, and make good use of variable names even if they are a bit long ( I have too many variables in my own code that are forgotten like temp1, temp2, temp_df, temp_nuke_code_base and more!)

The importance of clean code in your startup's success cannot be understated. Not only can unclean code lead to costly errors and bugs, but it can also make your code more difficult to read and understand. This can have a major impact on your startup's bottom line, as developers will need to spend more time working on your code if it is not clean.

There are a number of different ways to measure code quality, but one common metric is the "cyclomatic complexity." This measures the number of different paths that a piece of code can take. The higher the cyclomatic complexity, the more difficult it is to understand and maintain the code. As a result, startups should aim to keep their cyclomatic complexity low in order to save time and money.

There are a number of ways to achieve this goal. For example, startups can use comments and clear variable names to make their code more readable. In addition, they should use coding conventions and style guides to ensure that their code is consistent and easy to read. By following these best practices, startups can ensure that their code is clean and easy to maintain – both now and in the future.

In conclusion:

Code should be well organized and easy to read.
Code should be modular so that it is easy to change or add new features.
Code should be well tested so that bugs are less likely to occur.
Code should be well documented so that others can understand it easily.
Code should be consistent so that it is easy to maintain.
Code should be free of any errors or warnings (within reason).
Code should be performant so that it runs quickly and efficiently.
Code should be secure so that it is resistant to attack or exploitation.

If your startup's code is anything less than perfect, you're doomed to fail. Make sure your code is clean, otherwise your startup is going down the drain.

Star our Github repo and join the discussion in our Discord channel!
Test your API for free now at BLST!

Top comments (17)

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!