But what about tech!? Here’s what we’ve learned after a year of developing our own tech.

in #technology6 years ago (edited)

Let me quickly introduce myself before starting off the actual post. My name is Vu, i'm 22 years old entrepreneur and developer from Serbia. I've got 2 successful IT startups in Belgrade and currently working on getting the 3rd one up in US. I've written and see a lot of tech being developed over the last few years, and here are some of the tips i've learned over the time.

  • Develop the tech in what you’re best at.

Probably the best advice i’ve got when it comes to development was exactly this — develop the tech in what you’re best at. Our initial drafts and prototypes of the technology we used for our applications were using all the fancy new programming languages and techniques because we’ve heard that someone is using it here and there and it’s really cool and new. So we dove straight in just to find out we have no clue how it actually works. Not only that we lost time developing in such an envirnoment but we had to rewrite it all, and that’s when we came to realization that we should just write it at what we were best at. And when we did, things started running very smooth. It is very important to know all the pros and cons of the programing language you’re writing the tech in, otherwise you can run into issues like scaling and maintenance that you really do not want to have.

  • Think big, think scale!

I get a lot of questions from people in the startup community that just started developing their own tech about scaling, and what i’ve noticed in most of the cases is that people ignore the „big picture“.

„We’re going to make it work with 10.000 people, and then we’ll figure out how to add more“

Well guess what, scaling isn’t just adding additional resources to your server cluster — the magic happens on the software level. You have to make sure your technology is able to handle a lot of users, and when i say a lot i’m thinking millions, tens of millions. A way we found to be really useful and practical for us is to map the functions of our system and see what happens when 50 million users try to access it. Many times when we thought that the function was written good and we were proud of it we ran a test on it and it turns out that it isn’t that great. Rewrite. Start again, repeat untill it turns green. This is where the first tip i’ve stated wins every time — knowing the ins and outs of a programming language we were able to write everything to be functional and scale great, while in the cases when we weren’t really sure about the programming language we couldn’t achieve the best results.

  • Less patches, more flow.

Many times during testing when we found that something isn’t working we created a quick workaround to get us through the testing. Soon enough, those quick workarounds became a part of the workflow and we were full of the small patches in our code. This is very bad and you should avoid this at any cost, as a structure like this is bound to fail at some point. Test something, see where the problem is, create a quick fix if it’s urgent and then come back to the point and integrate that patch in the main work flow of the tech, even if it takes rewriting that part fully or even the whole thing.

  • Utility is great, develop as much as you can.

When we were stuck working on a big problem we’d take a break from it by working on something smaller or something that can help improve the general workflow. Usually those were some small utility classes and programs that helped us test and pinpoint some big holes in the system. We developed things like chat bots to help us test our chat tech, sophisticated penetration testing agents, database fillers, internal chat system — literally anything that could help us just a little bit. Of course, writing these little utility programes shouldn’t be your primary focus but more of a side task when you start hitting a brick wall with something bigger.

These are some of the tips that my collegues and i found really useful for building and sustaining our tech. I’m glad if you found some of them useful and if you have some to add write them up in the comments section. Thanks for reading and stay tuned for more techy blogs.