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

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

Developers Learning

leave a comment

In the past year I’ve realised that learning is a key aspect to developing and staying in touch with what is current. Essentially, there are two ways of doing this:

1) Adapted learning: This is when some members of your team have acquired a skill which is used in the currently project. You see how it is being used, and try to catch on and try to mimic the usages yourself at a different point in the project.

2) Educational learning: When you are on a project, in your spare time you come across a new technique someone might have suggested, or read it in a book. You try out some examples, and evaluate to check if it is really a good fit. Once satisfied, you try out the technique in the real project, and once satisfied, bring it up with adapted learners.

This works well with open source projects, such as Accuracy of by Bernardo which offers powerful potential over its rivals in Acceptance testing which replaced the existing way of automated testing we were using.

Now, this does not mean all devs can be classified into these two categories, but rather, a pattern of exchange that exists. Someone might know autoboxing, while others may be familiar with generics. All this learning however comes into play via learning exchange that takes place thorugh efficient-pairing as mentioned in my previous blog.

Written by zkashan

August 11th, 2008 at 11:03 am

Posted in Learning,pair programming

Tagged with , ,