Vanguard Coder

Simple Life of a Keen Developer

The Kashans Test

leave a comment

Joel did some excellent work in helping evaluate if we’re quiet there yet or not in terms of the inefficiencies we face during development and how much hair pulling needs to be done to just write code. Twelve years on with “Agile” being attempted it’s worth a review.

Working as a consultant, and talking with other developers,the attitude to development is “You can’t make an Omelette without killing a few people”, so the general approach many developers follow is just follow the process and get on with it. But it’s worth checking where you stand. It’s definitely more concrete than the Drake Equation.

Kashans Test

1. Source Control (+1 if you have one, -1 if you zip and merge, or use excel to track changes, 0 otherwise).

2. How long do stand-ups take (+1 if 1 min/person, 0 if more, -1 for what standup?)

3. Are there automated UI tests (+1 for yes or if not needed, -1 for none).

4. How long does the build take (+1 for <15 mins, -1 for more).

5. Do you get the “talk” if you break the build (-1 if you do, +1 if you don’t) – team spirit is important, but the underlying cause needs to be checked if it breaks a lot.

6. Do you have requirements to work against (-2 if you don’t, -1 if you have access to people that do, 0 for some document, +1 if there are stories).

7. As a developer are you required to be “well rounded” in large projects – i.e. is the project missing a PM, BA, QA, User (-2 if missing some, -1 if missing one, +2 if all are available).

8. When developing do you get OutOfMemoryExceptions, dribble your fingers on the table for build to happens, tests to run, etc… (-1 if you do, +1 otherwise).

9. Do you have 55 hours weeks outside release cycles (-1 if you do, +1 otherwise).

10. Does your company host developer social events? (-1 for no, +1 for yes).

11. Do all Devs have local test databases and are able to check in database changes using delta scripts? (-1 for no, +1 for yes).

I wouldn’t be surprised if this needs review in a few years with practices being adopted and standardized depending on the size of the company and the developer community in that area.

Written by zkashan

March 9th, 2013 at 5:52 pm

The Truth about Development

leave a comment

If we’re being honest, I think a lot of us would like to continue to be developers, learn and invest ways in making coding efficient, quick, maintainable, and flexible. In essence, we’d like to remain forever young. However, time flows in one direction. And the tracks we leave behind get etched in what we do and write. I still remember the first team I worked with, the first interview, the first code review. They’ve left their mark.

As a Developer, I’ve always believed in the power of technology. But it’s a mean and not and end in itself. And coding and automation may not always be the only solution. A strong skills in analysis, project management, and being able to research the best solution and architect-ing a solid design are all just as vital but are sadly left out in most of the evaluation processes.

As a consultant it always puts things in perspective to deliver a working evolving system whether it is a throw-away application to be used for a year, or something that will remain a core part of the system 20 years later, it is the question of what is the best system and solution to what I’m being asked to deliver.


Written by zkashan

July 24th, 2012 at 8:46 pm

Saving the pennies, spending the pounds (or dollars)

leave a comment

I came across a post about pennies in the process which reminded me of some of the high-ceremony estimation sessions that I’ve been to that seem to run days, and not everyone is utilized, and some in which I had to come up with estimation on my own with some consultation with other people in development.

Canada is planning to get rid of pennies. I went to Lebanon recently, where there is no concept of pennies. A few other countries are going down that route as well – primarily due to inflation where the purchasing power has been eroded, and to manage them becomes expensive.

Having read a brochure by GreySpark, it reminds me of the the process drag created which elongate the project such as filling out forms at the end of the different stages (which no one reads, and is only there due to the process), not considering non-functional requirements, or working on slow-dated machines, and large solutions with many projects which cause development time and the learning curve to increase. Using tools such as Resharper save a lot of  typing time, makes running tests quicker (compared to what Visual Studios provides for MSTests). Avoiding creating custom frameworks, or solving small problems which have already been solved is also useful (e.g. ConcurrentDictionary in C# for storing values with its AddOrUpdate method, System.Lazy for singletons, an using (P)LINQ rather than writing loops are .Net 4.0 code specific examples).


Written by zkashan

June 5th, 2012 at 6:26 pm

97 Things an Architect Should Know Review

leave a comment

“97 Things an Architect Should Know” is an excellent book which reflects on experiences of people who have practiced agile as well as those that have been in IT for more than a decade (It has some (ex) Thoughtworkers, but interesting none from Conchango). It sheds valuble inside into the work of architect as well as reiterate some important points (e.g. software is evolved and not developed, commit-and-run is a crime, avoiding “good ideas” which can effect the project negatively quiet easily, etc…). I think it is a good quick read to reflect on ones experiences on different project and how other people went on to resolve those issues, and potential project smells which no longer feel something that need resolving. However, to keep the book concise it was kept in a point format, which makes it hard to remember most of the points as these come about from experience and retained rather than learned beforehand. Nevertheless, it could be used as a reference to see how we can improve ourselves and excel.

Written by zkashan

May 12th, 2009 at 9:17 pm

What is the difference between an MVC and MVP

leave a comment

M – Model, V – View, C – Controller, P – Presenter

Many if not most of the people do not know the difference between the MVC and the MVP pattern. Recently, when someone asked me to describe the MVC pattern, they said that it seems like I’m talking about MVP. Most of us thought that there indeed was no difference, but in fact there is – and its very small.

In MVC, the Controller and View can talk to each other, and both can send messages to the model. In MVP, all communication is directed via the Presenter, and the Ms and Vs do not communicate directly, but only the P can send data to the M, and the View and/or its Interface (decoupling!).

Written by zkashan

November 23rd, 2008 at 6:28 pm

Posted in Coding Practices,Comparative

Tagged with , ,

Knowing When to Log Errors

leave a comment

In a recent chat iwth Daniel Bodart, I realised that after programming Java over the past few years, it offers programming an open option of handling bugs. Handling errors needs great care and scrutiny and care. When writing error handling code one has to decide – do you really want to handle the code?

It’s not too uncommon to encounter a code which logs every single error (e.g. user did not enter his telephone number in the online form) into a log file. This results in a horribly long, few gigs of error log file daily depending on site usage. Then looking through that file is like finding needle in a haystack, unless the large log file in itself does not cause issues serious enough (system hangs, time consuming to search).

The idea here is to either handle an error as it is if possible to handle it, otherwise should we let the system crash on errors we don’t know how to handle giving the user a negative experience. 

If we had 10,000,000 users signing up for a £20 service. The system does not work for 0.05% of them which results in 5,000 users having issues resulting in £100,000 direct loss of potential revenue. It also depends on how fast the technicians are in catching the error, thus if we catching it after 1,000,000 users used the system, the direct loss of potential revenue will be reduced by a 10th to £10,000, all the while causing no issues that the remaining users that might have had the same problem. But any potential loss is hit on the revenue and needs to be balanced out.

Written by zkashan

September 8th, 2008 at 3:24 pm

Posted in Coding Practices

Tagged with , , ,

Variables and Names


I’ve been working with C# for the past few months, and never encountered a “var”. Mark commented seeing var’s all over the code base he is working on here.

It probably happens that once in a while a person encounters ancient code base, or people still using old methods of coding. I remember a few years ago in VB class at university, they were saying that to improve readability, variables should be named as “String strReceipt” and “int intTotal” which was probably the most ridiculous thing I’ve ever heard.

Even worse was the (Q)Basic era where variables were variables were named a, b, c and when there were too many, I was told to keep some sort of documentation for future reference as to which variable is for what for purpose. No matter how primitive, this can never be beautiful as some things I found in my previous blog about Ugly Code turning beautiful.

Written by zkashan

August 15th, 2008 at 2:23 pm

Posted in Coding Practices

Tagged with ,

Ugly Code

leave a comment

I came across a horrible piece of code written a few months ago. It was a client side javascript code which was ambiguous, used Basic era variables like a, b, c and relied on checking all user entered field every few seconds. The very first thing I remember while looking at this code was screaming like a child. It was as if I had lived my whole life in a cave when I thought I had seen everything possible.

When I first looked at the code it was if it were suspended in time by the person living in a private world of darkness where programming dimensions such as decent variable names and exploiting modern technology for problem-solving.

I went back at the code, and decided to have a look in between the lines, keeping in mind that I shouldn’t be surprised by what I see because this was not normal code, and not just Java script, but was in fact Basic parading around as Javascript.

Looking at the code even deeper I began to talk to the person that wrote this code. Of course, the person who actually wrote this code had left some time ago. But it was more like the code I was talking to. With it line, it had a feel to it. What kind of world is it where ugliness is the norm, and beauty, a potential deviation from the norm.

I guess the answer is that it does not matter! Because the old saying “Beauty is in the eye of the behold” is true! No matter at what time in the future, or the past, where ever this code is written, beauty is in the eye of the beholder. The code belonged there exactly as it was. It did not need any rescuing, nor any help. I can not make ugliness a crime, because beauty is not skin-deep. We should allow code to be different.

A vital lesson learned which I thought was impossible.

Adapted from TZ.

Written by zkashan

August 5th, 2008 at 11:23 am

Posted in Coding Practices

Tagged with , , ,