Stuff about software development, agile and testing

Saturday, September 27, 2008

I give up...mysql

Its over with mysql. I hope that I don't see it again. There are things that you love about database and installing them is not one of them, especially when it comes to MySql. No no I am not trying anything fancy, all I want is to get Mysql up and running on my new Mac book pro.

The installation process goes through fine but when time comes to login, mysql comes back with aceess denied for ''. According to the documentation, root user comes with no password...hmmmm, never mind. Lets move on.

My first reaction was , maybe its using some old my data folder that I migrated from my old mac book pro.

So I tried running /bin/mysqld_safe --init-file=reset-root-password-file to reset my root password. The init file contains an update sql statement to update mysql.user table with a new password for root user. To my surprise the situation did not improve at all.

Next I tried starting the mysql deamon server with -skip-grant-tables option and it worked. No don't start celebrating yet, when I said worked I mean now I was able to connect to the server using my mysql client. And when I looked up the user table I discovered that I don't have any users. Why ? I really don't know. At this point I have already spent 2 hours figuring out the problem but not ready to give up yet. I looked it up on google and as usual I am not alone, some mysql installation doesn't run the post installation script to create users and grant permissions.

All mysql installation comes with a mysql_install_db script under mysql/scripts folder. Apparently for some installation you have to run it manually. I am not sure why?.

Anyways, finally I thought I got it. So I went ahead and ran the mysql_install_db, it fails. This time because of 'duplicate entry for localhost-'. Apprently this happens when your hostname is set to localhost. Maybe this it, so as recommened I changed my hostname to my name and hooray the script ran successfully. Now I am ready to build the rails app I was planning (the only reason I want to use mysql in first place is because my pair has that setup) for in the first place. But my mysql server doesn't start up and it doesn't even show any error message.

I think 3 hours a lot of time to setup a database and I cannot take it anymore

Thursday, September 18, 2008

What makes design...simple

Last weekend in the “Simple Design and Testing Conference” we had a discussion on “What makes Design Simple” and this is a summary of the discussion we had along with my thoughts.

Well before we go further with in our way of defining simple/complicated design we have to step back and first answer why do we design?

We design to be productive and I don’t do it if it is below the DesignPayoffLine. Now if you read What is software design which I highly recommend you will learn that we design all the time, when customer approves a story he/she makes a design decision (this is interesting, some times we evolve to complicated design when stories are not broken properly), when we write tests (we do test driven development) and programming is also a design activity. So I guess we are always designing with or without knowing it.

Being an agile developer, we don’t focus ourselves on BUFD (Big Up Front Design) but rather we believe in evolutionary design, a design that grows as your system grows and there are benefits of doing that which I will not discuss here (read One of the key aspects of the evolutionary design is to do the “simplest thing that could possibly work” nothing less, nothing more. There are couple of things that needs to be noted here, “simplest” and “possibly”. Simplest or simplicity is your shortest path to the solution i.e. getting your idea from your head to screen as quickly as possible. And why it is possibly? Because we are not sure whether it will work and that’s why we write test to make sure that our idea works.

But the interesting part is we all start simple (I am totally ignoring the fact that there are teams that start with 200 page design document from day one) and it gets complicated over time because it starts doing more work. But if we could restrict ourselves to keep it simple for tomorrows need tomorrow then I guess we can preserve simplicity and this is where refactoring step fits in. Refactoring is our way to simplify things when it gets complicated. Einstein once said, "As simple as possible, but no simpler." And I think that makes sense here.

Wait a minute we haven’t defined simple design yet? I don’t think I can define simple in two lines but lets ask the question differently, “How will we know that our application design is simple?

Software with simple design will enable team members to quickly respond to change. And as your design deteriorates, so does your ability to respond to change. This is really critical for agile projects (again ignoring rest 70% of teams who don't believe in agile, they really don’t care) because we embrace change and customer satisfaction is important to us. Kent beck calls it “reversibility” property of software. If we can change our decisions quickly it is not a big deal to get them right in the first place and that means less planning upfront (we are wrong most of the times anyways). There are some really good second order benefits to simple design, we get our work done sooner and it is easier to communicate our work with others (I am not sure about you but I still work as part of a team, collective ownership rings any bells?). Above of all it is less stressful to work with simple design.

So how can we keep our design simple? Testability

I absolutely agree with James Bach on " there are no best practices" but rather appropriate practices and I think the appropriate practice to keep your design simple is continue to write tests.

Testability is a characteristic of software application that provides ability to developers to write tests for their software application. In the world of TDD, we derive our design from tests and having that ability is very important. In fact if it is hard to write test, developers will stop writing tests especially new agile developers. It is very easy to get into “code and fix” mode under agile radar. If you are the only manager reading this article please pay attention to your developers when they say it is hard to test, this could be good indication that application design is deteriorating.

While discussing “What makes design simple” in the conference, Brain Marick raised one interesting point, we should strive for habitability, “The characteristic of source code that enable developers feel like home and place their hands on any item without having to think deeply about where it is”( read We do spend good portion of our time everyday inside the code we are working on and habitability makes working easy. I guess more appropriate answer to the question “How will we know that our application design is simple?” would be habitability. If it is easy to work with your design, it is simple.

If you are still with me then probably some of these makes sense but if you were looking for top 10 practices for simple design sorry to disappoint. The only take way point is “Design for today, not for tomorrow”