csongor.fagyal.com

The Proper, the Fast and the Reusable

Web programming – on which I basically mean “creating whatever websites”, BTW – is a rather special kind of animal. In introduction to unit testing I wrote about how it is NOT a special case, but that is only one way to look at it – there certainly are some differences which might require a different perspective from the developer.

Proper != Fast

Many programmers out there would argue that (web-based) projects fail because they are not written properly – that is, certain “script kiddies” with no serious programming background just hack code together using seriously flawed approaches (and languages, such as PHP). Without proper design, without knowing anything about Design Patterns, Unit Testing and whatnot, we end up having spaghetti code, global variables, God objects and whatever display of other anti-patterns, so in general a big pile of… well, unmaintainable and buggy code.

On the other hand, some of these script kiddies might argue that by the time “proper programmers” has written their unit tests, prototypes and abstract factories, they have already released their code and are on the Bahamas drinking cocktails. And, by the way – they would add –  their code runs on a twenty years old 386DX, and not on a cluster, so who is being proper here?

Proper (well thought-out, well designed, well written and tested) code might actually take more time to develop than fast (quickly hacked together, non-standard, usually faster) code. Apollo 11 was built in a hurry, we still wonder, how it really got to the Moon – however, X34, which is a much better design, and which was given a lot of development time, never really got anywhere. On the other hand, script kiddies do not build spaceships: they build websites prone to SQL injection attacks and bit rot.

Let’s say your site needs to read a config file. The Proper might create a grammar and a parser for the config file, write some unit tests, put the whole thing in the repository, write the docs, then start using it. It’s done in 2-3 days, and it is proper. The Fast would just use Perl and make the config file a Perl file that defines a hash, and simply read and eval it int 2 lines of code. It’s obvious that the Proper did it properly and the Fast did it fast, but who is right?

Time-to-market

The general rule is to write proper, maintainable, proper code. It just makes sense. What people often forget though is that time-to-market issues cannot be disregarded. Consider the Optimus 2X by LG, which is a totally broken phone, yet it sold in millions because it was the first dual core Android device. Do users curse LG for the random reboot? Sure they do. Does LG lose the trust of some of its buyers? Sure it does. On the other hand, it’s better to have customers who don’t like you than just not have those customers anyway. You fix the software later, and release a patch. Business decisions often contradict proper design.

The same is true for web development. Providing a solution for a problem first on the market can be much important than writing nice code. First, you release. Next, you make money. Finally you refactor. Basically writing nice code is sponsored by writing bad code. It’s also important to note that well encapsulated, proper code can often be slower – considering both CPU and I/O use – than some hand-optimized, unstructured “linear” code. Just imagine the code used for fetching an object from SQL using an entity wrapper as opposed to some pure SQL queries that push only the relevant columns into hash arrays. You can save some money on hardware if you optimize for throughput and not beauty.

Is that the way then? Just hack together something, release it, and worry about maintenance later?

Fast and improper – expertise makes the difference

When it comes to deciding “how properly” you want to design and implement a website, there is just no general rule of thumb method. Yet one thing is true for sure: it’s not just a technological decision, but also a business decision. If writing “improper” code helps you to be on the market faster, helps you to be ahead of your competitors, you are basically pushing development cost into the future. In other words, with fast development you are actually taking a loan of time, because eventually you will have to pay to have proper code, there is no way around that on the long run. And if you are unsuccessful with your project, it’s a loan that you don’t have to pay back.

And here comes expertise. Agile development, for example, requires very good programmers, otherwise you end up cargo culting (at least in my opinion). That’s also true for “fast and improper” development, since you must not code improperly because you cannot code properly – instead, you do so because you make a wise decision by making a compromise. Improper coding must happen on purpose, and not by chance.

Reusable components

What I find a suitable approach – and other might not agree with this one – when one opts for improper development methodology is to focus on using and creating reusable components, using which you can quickly create websites. When taking a look at the success of certain Perl projects (e.g. Booking.com), one might argue that a big part of the success is due to the existence of CPAN, the Perl module library. The modules on CPAN come with unit tests included, many of them are of high quality, smoke tests are run daily, and so on. If you create your system using (mostly) CPAN modules, sometimes all you have to do is integration testing. I prefer using components to using full-blown heavyweight frameworks.

Web development consists of a lot of boiler plating. You get data from a database, and display it. You take a user form, verify the input, and store it. That’s basically it. Sometimes I think most websites could be substituted with a big config file each. Having your system made mostly of components is a step towards that – all you have to do is find the ones assembling those components.

Seniors and juniors

Assume that you can hire two senior (meaning: good, experienced) programmers for X / month, or you can go with six junior (meaning: not so good, inexperienced) ones. If your main goal is productivity, which option would you choose?

I would say that’s a trick question, because you should get one senior and three junior programmers. The senior one does all the design tasks, focuses on the the most important points in the system, and also spends the rest of his time hitting the junior programmers with a stick when they don’t do what they are told. The senior programmer chooses or even writes the components, and teaches the juniors to properly use them. All you have to make sure is to give him enough sticks, and things start working. Once again, this is a business decision.

Another reason why I like having a team with non-uniform knowledge levels is because most (web programming) projects include a huge (>50%) amount of basic site building tasks. Senior developers will not be happy doing that: someone who has created 1294 forms in his life will go mad when he has to create the 1295th one.

Comments

comments