Tag Archives: Development

keeping your code in shape

Not too long ago ID Software published a document detailing its coding guidelines. It makes for interesting reading and we can all learn something from it.

I certainly picked a few rules from it as I was putting together a set of coding guidelines for cloudbase.io.

However, web development is very different from game development. Iterations over a piece of software in the web world can be as brief as half an hour, production bugs need to be fixed and released promptly. When building a game you spend months testing and refining your code.

Fast iteration is one of the biggest advantages of web development, a centralised code-base that can be adjusted and updated without needing to re-distribute your software. Unfortunately the speed of development and release is also what causes “spaghetti” code to appear.

What I thought I’d do is try to set, on top of some detailed coding standard rules, more architectural and structural rules for the code. These will hopefully guide developers when they are furiously fixing issues and adding functionality.

These are in no particular order and I’m writing them as they come to mind. I would like to hear from developers and CTOs out there to complete and adjust this list.

  1. If parts of your software need to interact with some code without knowing its entire structure and meaning, in an interface-like style, then it should be an Object. Weakly typed languages are no excuse to produce code that will be harder to debug and maintain in the future.
  2. Your variables should be your comments – use readable variable names and split an instruction in three separate steps if needed for the sake of readability.
  3. Think big – when fixing a bug or adding new functionality think about the rest of the code and how it interacts with what you are re-writing, you are most likely missing something. Then pause again and think even bigger, what will your business look like in the future, in which direction is it heading, perhaps you could add some hooks in your code which will make it easier to re-use as your software evolves.
  4. Objects are nice and keep your code clean – however, if the object you are creating will not be reused, or you already know it can’t be reused because it’s not going to be compatible with the rest of your code, then it probably shouldn’t be an object, keep it simple.
  5. Divide to conquer. If your application can be separated in different components, for example an API and a management console, make sure they can run independently from each other. If one is down ideally it shouldn’t take down the other. This will also make your code easier to re-engineer, you will be able to do it one little logical component at a time without having to go through a monolithic rewrite which almost never works.
  6. If you are writing a 10 lines IF statement there’s probably something wrong with your logic, review and simplify.
  7. Prototype your code quickly but make sure to cover the entire business case from beginning to end. Once you have mastered all of the use cases, write the code for your application.
  8. When adding new functionality also write a test case for it.
  9. If the functionality you are building already exists in a library your project is using or could use, use that library. DO NOT REINVENT THE WHEEL.
  10. Write some java-doc style documentation for your functions. It will make other developer’s life easier, your business will be able to produce a documentation for all of its code.
  11. Write comments to explain the logic of your code if it’s needed. don’t state the obvious.
  12. We are building web apps. The web server is already multi-threaded, each page loads in its thread, you don’t need to spawn sub-threads in a page.
Tagged , , , , , , , ,

mobile cloud and connected apps

In early 2012 I founded cloudbase.io. Ever since then I have been coding, networking, tapping on smartphones and generally running around like a madman to keep on top of everything.

I have always been interested in mobile development. However, while I was a networker in the web-development sphere, I was a basement-geek when it came to mobiles. Cloudbase.io has changed that, it forced me to go out and meet with the community of mobile developers.

The first thing I noticed is that most of the developers I met were purely mobile developers. They had never worked on PC applications or web development. This might explain their behaviour when I met up and talked to them.

While I was pitching cloudbase.io to mobile developers the answer I got most often was: “why would my app need to be connected to the internet?

It felt like talking to PC application developers in the 90s, before the .com boom.

We are all talking about the cloud as storage for consumer data but there’s much more to it. Thousands of applications are released every single day and only a fraction of these make use of the potential of internet connectivity, now ubiquitous on smartphones. There is a wealth of data out there just waiting to be queries, and more importantly collected, by mobile apps.

We are at the beginning of this transition and I wouldn’t be surprised if 2 years from now all of the application we interact with will have a “network” component. Be it social interaction between its users or “augmented data” fetched from all over the net in real time.

Tagged , , , , , , ,

Celebrate diversity

Another post about my experiences with startups.

The one important thing I have ascertained about programmers during my career is that good ones are hard to find. Furthermore skillful developers tend to be ego-maniacs (I am no exception). The people generally portrayed in films as shy “nerds” are really expansive, loud and boastful persons. After all why shouldn’t they be; a startup’s most important assets are its people, and developers are a vital part of the organism. On the other hand it is also true that everybody is important but nobody is necessary.

In all the startups I’ve worked for, particular emphasis was put in the recruitment process, especially whilst hiring members of the initial core team. Which doesn’t mean only finding smart competent people, but also making sure that they’ll fit in with the rest of the team. Therefore it is very important to have every member of the initial team meet the candidate and make sure that they will be comfortable working with them; even people from different departments, marketing directors should meet programmers before an offer is made.

The other thing you have to make absolutely sure of is whether your newly-hired programmer can accept the technical leader’s style. The manager/CTO (call it whatever you want) has to be flexible, but at the end of the day he/she is still running the show and you can’t really afford to have a small team destabilized, especially when the disturbance undermines the leader’s authority.

I have had to interact with quite a few managers, each one with a different approach to the development process. The two most common and distinguishable modus operandi are certainly the autarchic and the unconstrationist (new word I just came up with).
The autarchic wants to be in full control every step of the way and put a two cents in every decision. The “libertine”, on the other hand, will take care of the big picture and leave the individual programmers to make decisions regarding the piece of functionality they have been assigned.

Neither attitude is wrong. However, I generally adhere to the more liberal approach, hence the title of the post. Being in charge of something every step of the way certainly helps prevent bugs from being introduced, if not because of a CTO’s superior experience because two brains are generally better than one. Anyhow if you try to be involved at every level of the development, from the requirements gathering and analysis to the practical development you’ll quickly end up being overwhelmed with work and with a crew perhaps not prepared to scale and be in charge of new hires themselves.

Contrarily leaving developers some independence in their restricted realm helps boost you team’s morale and prepares a normal programmers to be in change of somebody in the future as the company grows. Admittedly this approach will leave the whole system more exposed to potential bugs, introduced either for a technical mistake or lack of wide-angle-view-to-future-developments of the programmer in charge. The second drawback of this method is that you’ll most likely end up with a code library written with very different styles, hence harder to maintain and get used to for new people. Be that as it may, I still stick with “Celebrate Diversity”.
There’s always going to be a better tool or programming style than the one used when developing something. However, asking a proud programmer to change his code and do whatever you asked for exactly your way is worse than a punch in the guts.

As I said before neither approach is wrong and it’s purely a personal decision of the person in charge. It is a very difficult balance to strike. Ego-feeding is good, keeps the spirits up and developers are more likely to work harder and better. Unfortunately, programmers are human and as you leave somebody in charge of a single piece of functionality there might be nobody to find that stupid bug which could have been caught in a second by an additional brain.

Tagged , , , , ,

With the benefit of hindsight…

During my short yet intense career I have worked for quite a few startups and small businesses. I want to talk about a phase most startups go through – Our application is crap, lets trash it and rebuild it from scratch.

Hindsight is something few people have and wisdom is just a myth, just a fancy name we have come up with to call our mistakes.
Nevertheless when a company outgrows the chrysalis stage and starts producing revenue and growing accordingly hindsight is one of management’s favorite words. It’s widely abused in every meeting. Who hasn’t heard at least once “With the benefit of hindsight we could have…”.
This special word makes the eager-developers brain click. There’s our chance to build the perfect application. We know what to avoid, we have wasted countless hours solving all the problems we found in our path before and we’re now ready to whip out the ultimate system.

Perhaps with a bit of hindsight, wisdom, or a wee little bit of both, our developers would realize that every time they start developing an application from scratch a whole new bunch of complications will crop up and will have to be solved. While this happens the management team who has promised to deliver in time to the big bosses is obviously breathing heavily down the programmers’ skinny necks.

This happened to me once, although we didn’t go as far as actually begin the development a countless amount of hours was wasted in meetings to trying and figure out what we were going to do and how.
The issue for many startups is that very often the software is developed hastily for lack of funding or time constraints. This generally leads to a structureless applications patched together at the last minute. That’s how it is and always going to be – and in my personal experience it’s definitely better this way than running out of funding because the entire process is managed by a megalomaniac-developer with serious ego-related issues.
Once the application is ready and the product is launched there’s never going to be time to stop. Look back. Amend emissions and non-blocking bugs until it’s too late. That’s just the natural process.

After 1 year of life the initial product will most likely be completely unrecognizable and changed/badly-patched in many of its core components. This will make keeping track of what’s exactly going on inside the software harder.
So now what.
The approach I’ve found most feasible and realistic is to gradually fix and produce documentation as the development progresses. A software, especially a website, will never stop evolving and the amount of feature-requests and bugs to fix will only increase with time, stopping the entire machinery to go back and fix is just not an option. However, whilst new functionalities are being added, they will probably have to be integrated with old ones. This is where wisdom can assist you. It is definitely worth spending a few hours more on each new piece of code to patch up the old part it has to touch. Gradually your development process will fall back on track and there won’t be any more wild panic because of obsolete or faulty routines and functions.

If, on the other hand, your software is rotten to the core and cannot be rescued, well, tough sob, you should probably have thought it through more carefully before putting your hands on the keyboard.

Having said that I’d like to add that rewriting an application is not entirely impossible, but it’s most likely going to be a colossal process which will require large sums of money.

Tagged , , , , , , , ,

Google pushes for corporate adoption

Google takes yet another step in its battle against Microsoft for domination of the corporate environment.

The software giant has recently released a set of APIs which will make migration from a Microsoft/any-other-system-you-may-use to Gmail incredibly simple.

“We’ve provided developer documentation and sample code that allows developers to build extremely sophisticated mail migration tools, some of which can be run by administrators to migrate centralized mail and some of which can be run by end-users to migrate mail from the desktop,” — Gabe Cohen, Google Apps product manager.

I couldn’t find any data about the usage of Google documents around. I expect the uptake of the application to be extremely high among non-corporate users. However, It seems that it will take a bit longer for small businesses and startups to get used to the service and start using it. Especially considering that most users have been educated in a Microsoft-ruled environment their entire professional life.

Google had previously released another set of tools to allow users and system administrators to migrate from most IMAP-based e-mail systems to Google Gmail.

Furthermore, as much as this set of APIs is a very interesting development, I hardly see a big corporation spending a considerable amount of dough and development time to migrate its entire system, similarly it’s going to be even harder for small business find the time and money to dedicate to this. Don’t take me to seriously now though. Companies like Capgemini, with 80,000 employees are in fact putting a first toe in the water and using Google Apps for some of its employees.

Nevertheless I’m sure all sort of open-source/free applications will sprout all over the internet to let disgruntled Outlook users switch to Gmail.

Tagged , , , , , , ,

Get every new post delivered to your Inbox.