Last week the company I work declared that “XP is the answer to our development process”. I have never worked in an XP environment before so it will be interesting to see how well it works. But before I jump into this I wanted record some thoughts I have about XP and then as time goes on I will comment on them if I gain any insights.
According to this years GITA program, http://www.gita.org/events/annual/28/program.pdf p. 21, I co-presented a talk about GIS XML Vocabularies. I had been planning on presenting this topic with Pedro Pacheco when we work together at GE but when I left GE I decided to let him do it without me. Apparently the program did not get updated to remove my name. Anyway, I hope it when well for Pedro.
A few months ago I pointed a colleague at XUL as a way to implement a user interface without requiring local installation. After doing a bit of research he mentioned theMozilla Amazon Browser to me. I have been intrigued by the idea of XUL and XAML since I first encountered them but MAB is the first XUL application I have actually used. It is not terribly polished but it gives you the feeling that a XUL application could be extremely slick.
I have just passed the six month mark at my new job. And I am learning a lot of new things, which is nice. However, I recently noticed an anti-pattern in my performance in my new job.
Anti-pattern: Developing generic technical services as a form of procrastination.
My basic tendency is to develop software “bottom-up”, by which I mean generic technical services first and then implementing the application logic on top of those. I had been at my previous job for six years and after a couple of years you start to really understand the domain really well. This bottom up development style served me well at my previous job because I, for the most part, understood the problems I was solving (and the environment in which I was solving it) almost with out thinking. It is very easy to write generic technical services first if you have a reasonable understanding of the problem and solution domains.
In my new job I do not have a good understanding of the problem domains or the environment in which my solutions will run. I have spent the last several months working on a small-ish project and I have spent most of that time work on generic technical services to support the actually application logic. At this point I have far more technical service code than I to application code. The technical service code does exactly what I intended it to do but unfortunately it is for more complex than is really necessary for my current project.
It is very easy to procrastinate actually learning the domain, requirements and environment by jumping into coding the technical services you think you will need. Unfortunately, the “bottom-up” development style really only works if you understand the requirements, domain and environment well. If you do not understand the problem and environment well you will just write tons of code that is either solves the wrong problem or solves the right problem inappropriately.
PS: This article was prompted by a couple of people I respect, David Hansson and Jamis Buck, blogging about mistakes they have made. I agree with David that the net benefits of transparency far out weigh the risks.
I happened across this interesting little tibit yesterday. It is a bookmarklet that generates a password based on the domain name and a master password. It makes it so that you can have a different password for every website you need to logon to without having to remember hundreds of passwords.
If you are reading this blog you probably already know this but… My new “permanent” email address is pezra AT barelyenough DOT org. I will still receive email sent to my previously “permanent” addresses but it is possible that this might change at some point in the future.