Tag Archives: coding

Code your own way… but design well

Posted by Airsign on 10/04/2012 None comments

These series of guest posts are written by the teams attending the Tetuan Valley Startup School 2012 Spring Edition. This post is from the Airsign team, formed by Miguel Páramo

A coder working on a Startup is usually told to code shitty and get over it. This is probably one of the biggest challenges and dilemmas a software engineer has to face when working on a startup. Going against all we have learned or, the opposite, minimize the effort, launch something quickly and improve with the client’s feedback and test if your hypothesis is correct.

There are different ways of coding. In fact, there are as many as there are programmers. One should code the way it suits him. That means that you should get rid of all those fucking topics about strategies, lifecycles or agile methods and start doing things the best you can always according to your objectives. There are some recommendations, but they are not mandatory. Engineering has some methods and process to do things well, but creativity hasn’t got recipes. So if you think your product does not need good code, don’t waste your time on it, that´s ok. But creating software is not only about coding. System design is an important step before coding and most tech entrepreneurs haven’t even heard of it… also the design techniques aren’t even applied by many of the technically skilled people.

What shitty code is like

Should it not be that important then? Well that is what this post about.

What are the benefits of good designing?

A bad design will lead to a bad code. A good design raises the chances of making a good code. This is the simple and painful truth, no exceptions. Furthermore, most of the bugs in a program are symptoms of a bad design.

When a system is well designed that means in a nutshell that it is divided on its very basic components and those modules behave well independently of the others. So if you made a generic database interface, it will be reused (and you fucking will) in some other projects. If you did a non-generic database interface then you will have to code it mostly from the beginning when you need that functionality in other projects. This is the same as saying that when a system is well designed all of its components can be reused in other projects or even be sold independently. It would save tons of time and money in the future and will allow the developers to code much faster and deploy better products in shorter time. It also will make it easier  for new teammates to understand the work and will increase their productivity making their’s less painful and easier.

On a well designed system, each component does a small set of simple tasks. With this philosophy, a big change on it does not compromise the rest. Also, a strong change on the system does not affect more than some of the modules. For example, you have created an awesome product with a black graphical interface. Now you have to change this colour to white… This can be the most painful task if you have to check hundreds of lines of code to find the colour variables and change all of them one by one. But if your system is well designed, you will have a very well known variable which references that colour and you will just have to change it in less than 30 seconds. Think about more complicated changes than a single colour.

Appliying this technique will allow you to code better and faster.

Testing the product will be far easier and if an issue is reported, then it will be very easy to locate it and fix it in a short time and just by changing the problematic modules. You won’t have to worry about whether your changes are messing up other things.

For all the previous facts, well designed components are more valuable and also expensive.

Then what are the cons?

Those techniques are meant to allow people to create code. So the final product is code and this is the interesting part, not the rest of the process or either the insights of a product. People only care about if it works and does what is supposed to do. Every person in this world can learn to code. In fact, millions of people code. But to do things well, extra experience and training is required. This stuff may be boring to learn and requires much practice to be done well and in short time. Not many people (including me) have the skills to apply these techniques fast while coding and those who can are expensive to hire.

will code for food

The conclussion is that it may be worth investing all the time it takes a good system design. I insist, do the things your own way, but there are some tips that will help you in the present and will save you a lot of trouble in the future. If you want to hire a coder for your startup, make sure he knows something about this and this. This is also interesting but in my opinion, the metodology name is irrelevant and should not have more importance than the engineering process.

Leaner code = Business success?

Posted by kpad on 19/10/2010 1 comments

These series of guest posts are written by the teams attending the Tetuan Valley Startup School 2010 Fall edition. This post is from the KPad team, formed by Damasia Maneiro and German Viscuso.

Let me start with a disclaimer: I’m a developer so I’m biased. As developers we often tend to think about projects, start-ups, companies and business in general in terms of source code. It is well known that when the code sucks it becomes much more costly to maintain and improve (and by sucking code I mean dirty code). This extra cost then impacts other critical areas: cost and risk of mismanagement increases, schedules and budgets get tighter. To sum up major areas suffer because the cost of error is huge due to the cost of code. Thus dirty code leads to business (or project) failure.

Even though this argument sounds compelling it’s actually misleading. The reduction of development costs has been championed by business people with the introduction of many dreadful techniques such as reducing the hourly rate of programmers to nonsense levels. For them cheaper code development equals business success (if code cost tends to zero the cost of error tends to zero). Moreover if the cost of code is reduced then business would have the ability to fail faster, leading to a quicker learning curve and a better business in the end.

Yoda smells code

But what if you’re trying to solve the wrong problem? What if your software is not as useful as you think? Even if you could automagically deploy at no cost a flawless version of a useless product that nobody wants and then kept rapidly iterating more versions of that crappy product, you would still eventually run out of money and time and your business (or project) would still fail.

Cost should not be the major factor in project success. It should be the value, the novel idea, the ability to ask the right question and provide the solution. After all sometimes limited resources help drive creativity!

For start-ups this is specially important since it’s all about the value that you’ll bring to the world. You’ll also notice that when a project starts from scratch coding is likely to be relatively fast even with low quality practices (which minimizes the code cost factor). Cost of software will become more and more important as the code matures but is only one aspect of the equation (and not the fundamental one).

Remember: you have the chance to do more of the right things and to do things more right. Start with the former but do not neglect the later as you make progress, that’s the path to your business success!