How do we deliver secure, fast, beautiful and meaningful applications means sacrificing the time to market? It is one of my personal every-day complications. Is there a magic formula? Maybe the answer is simple as: don’t overthink it.

And so it begins

Whenever I begin with a new project, I tell myself: “Humberto, you must write a better software this time!”. And what does better means for me? Well, it means:

• Writing more meaningful comments.
• Test my software in a more efficient way.
• Give my project a greater structure so it can be greatly understood.
• Dive deeper in the language I will be using for the project.
• Have fun while writing it.
• Ensure the development pipeline gets more and more robust.
• Raise the quality of my products by empathizing more with the end-users.

As a developer, this list of thoughts grant me the ability to keep growing from project to project. It teaches me how every little project is an opportunity to learn something new and to, slowly but steadily, become a better software developer each day.

However, this turns out badly because of my own anxiety. Is this library good-enough? Should I write tests for this? Is this implementation the best? Does the client uses a VPN behind a Tor proxy? In the end, it makes me think about how am I underprepared for the job I’m doing. It even makes me think about switching my profession or just constantly ask myself (and Google) if the work I am delivering is good enough for the money they’re giving to me.

You won’t be an expert on everything

There’s no way you can become an expert on everything related to a subject. To be fair, there is no way you can be an expert on anything. There is just a gray spectrum of knowledge, where some people know more things about an specific subject, and some others might know a little less. In the end, the thing is that you can always learn something and know some more about it.

Did someone told you he/she is The Expert on a subject? Well, they lied to you, but it is not their fault actually. There is people that love encouraging the expert classification and gives this people an ego-boost. It does not mean giving people courage and value for their work is bad, no, it depends on the person. Some people might take it like a nice appreciation of their work, encourage them to keep learning and becoming a greater code-wizard, but some others just step into a superiority brick and start taking their own knowledge as the only source of true. No one deserves to feel inferior, no one, but some people just like to brag about their knowledge without giving empathy in others lives. You and I cannot do anything about it, so let’s move on.

Raise the bar

If you like to learn, then don’t worry, you’ll eventually become what you now see as an expert. It takes time and dedication, but eventually you will get there. There’s only one condition for that: constant improvement.

We humans are so amazing we are able to see into our own future. This ability helps us make plans ahead of time and prepare ourselves for the different probable outcomes for a determined situation. Also, when you are a developer, it gives you a roadmap of the different subjects, tools and languages you need to learn in order to create better software products.

That is the reason we try to learn something new in each project, and that was the reason I kept having problems while working on some products. What if I am missing something? What if I am using some outdated library or plugin? Should I tell the client about all of this? And the answer to all of these questions will give you the same, useless, answer: it is actually not that important.

Money don’t grow on trees

A wise person should have money in their head, but not in their heart.

– Jonathan Swift

As these hard questions won’t get you anywhere, wasting time in them will take the project to its doom. The value of the product depends on many things, but the most important will always be the ability to do what it is supposed to do. Simple logic, right? What? Isn’t that simple? What are you talking about? It is just a bunch of code! I’m kidding, of course, but you know this is how your manager, the client and/or the product owner oversee the product.

Time to market

If you keep asking yourself all of this technical questions, you’ll eventually die without having built anything. It is impossible to actually get a project straight from the beginning, it just can’t happen. There is always minor and major changes, Q&A, new features and some of them might sneak into the product, and some of them won’t.

While some of these questions might become a blatant –”I told you!”– later on, they slow down the development process. This means that the product will later reach the customer’s hands and, consequently, generate losses for our company and the client. Is better, to go out with a frankenstein Minimum Viable Product that the users can take a look into, than a polished app that is delivered 3 years after it was planned.

Maybe it isn’t what the user was looking for in the first place

The most difficult way of testing a product is to let the end-users take a look into it. Software can’t be used by users without some entry-level functionality, and getting that functionality might need a little bit of time. When your product reaches the well-known: “Yeah, this works, but please don’t click there as it is just a placeholder” stage, you should run out and start looking for end-users’ reviews.

The sooner you get the users actually using your product, the faster you’ll have a bunch of features and bugs to work on. To get this working, you need to stop being a perfectionist, and actually deliver the product.

Bring the balance to the force

Thinking all of this left me with these two, equally contradictory, doubts:

• Should I worry about every single detail in the project in order to keep learning and grow as a professional developer?
• Or should I just deliver and #BUIDL the actual product?

The answer to both, awfully-written, questions is the same: No.

Deliver fast

There is no need to reinvent the wheel, we live in a programming-era were you can find all kind of resources online, from libraries to complete frameworks. There is no need to waste time writing something that you can just npm install. If it eases your life: use it. Don’t hesitate.

Remember that you’ll spend an etternity enough time fixing bugs and writing new features, so you might as well oversee some stuff as long as it generates a decent amount of technical debt. Early this year I wrote about technical debt and how it should be handled, but the only thing you need to know is that there’s technical debt that helps out projects by easing the development process.

Deliver quality

Also, writing software means delivering usable, top-notch, real-world applications for our customers. The bar is pretty high, and it will only continue to get higher as we get more and more globalization around us. Nowadays an application to be successful isn’t just about performance, I mean, yeah, it matters, but users will look for good design, offline capabilities, security and a bunch more of different considerations.

You should be aware of your own capabilities, of your team’s capabilites, the project’s scope and the customer’s budget. It is fair to extend the development schedule if it means adding a great feature that’s going to raise the product’s value. It is necessary sometimes to ensure security. And it is OK. It is OK to actually taking time in delivering a good product but you must be careful and choose wisely on which features are critical to the customer and build upon that.

True balance

There is no need to tell that, utopically, we will always deliver an amazing product in less time that the client expected, but also, there’s no need to say that it is mostly impossible. There should be a balance, and to help you out, I’ve written a simple checklist for any feature you might be overthinking a little bit:

• Will it impact on the end-user in a way they can’t interact with the app in a specific way?
• How much time will it take to build and/or fix this feature?
• Is there any chance this can be added/fixed after launch?
• Are there any dependencies within this feature?
• Does this feature fits into the customer’s budget?

As you answer this questions, you might come to the conclusion of what is best for the project. Remember that it is not possible to get everything right from the beginning (that’s why refactors existed, exist and will keep existing) and some things may need to be re-visited in the future, but also keep in mind that you’re building something that needs to be tested and used, so don’t waste your time wondering about Tor proxies behind VPN’s.

Conclusion

Maybe it feels weird to worry about all of this stuff, but that’s what makes you a true professional. There will always be this impostor syndrome in your head, but use it as a way of learning new stuff every day. Also, being aware of the business implications of your development makes you a greater asset for the team and gives you the ability to look forward into real management and project development.

As always, you shouldn’t be afraid to ask, if you’re unsure, get in touch with other developers in your team. If you’re too shy to ask them, then you can go into StackExchange and ask the interwebs for some advice, but no matter what: trust yourself, after all, we’re all just learning.

For comments and feedback, you can find me on Twitter as: @humbertowoody.