"How to Start a Project" or "Chaotic Project Management, part 2"

How to start a project?

Get a reference point.
Whatever it is.

Good chances are that the project is based on an emotional desire. No one wrote a Specification. Some one knows one part of the project, some one else knows another. There's no one 'oracle', no one place which holds the whole information in an ordinated manner. No constant reference point which one can work by, sometimes no one to ask either.

A few years ago I lived in the country side. One night I went out for a run in the fields. The hour was 22:00 and the fields were much vast and dark than I imagined them to be.

Instead of 20 minutes run, I found myself unable to position, running around in circles (probably, I saw nothing). After a while, when I started loosing patience, I decided to stop choosing different directions every time I believe I run in the wrong direction and instead to find a light source and run towards it. 10 minutes later I found my self near the lights of a small village street far from my home. I continued walking down the street and from there hitch hiked home. The whole adventure took something like 90 minutes.

When you get a project, look for reference points.

Start building a model with what you have. A model shouldn't be a specification document but the actual thing (if it's a program, you should actually program it).

Always try to understand the small details, they will hold the keys to understanding the whole system but never try to implement all of them in the model.

Cling to the big reference points.

• What are the main objects of the project?
• What can't the project work without?

Build it up together.
Don't try to cover 100% of the cases.
Build the simplest implementation.

Remember, it is cheaper to build 2 tools which do specific functioning than building 1 which does both. It's much pricy to build or buy a Swiss Knife than a simple set of tools for each function needed.

In databases, many times - it's chipper to do 2 SQL queries with a UNION instead of 1 complex one.

Never try to fulfill all the functionalities of the project with one tool. It's cool and interesting but it might cost you your seat. If two functionalities are ment to be processed by one tool, it will naturally happen in a later phase - when similarities of the two different tools will intrigue you to commit this change specifically.

As you continue in the process of building this model, you will naturally see what's central and what's not. It will be possible for you and for your client to ask the right questions and get the proper answers.

Along the way, keep an open eye on the weak points of the model - write them down, think about them, plan and finally refactor.

Chaotic Project Management, part 1

I always thought that writing a good spec before programming is mandatory.

I like short but frequent discussions where a project spec is being written. I found out that having a spec (Agile, or not) is something mandatory. Ever since I understood I have to demand a spec from the customer, even if I have to sit down with him and write it together (frequently), programming became a much faster and easier task to commit.

It is funny that in our world of 'thinking' people, so many times we don't think and rush to program without a true moment of thinking.

If you know the road, you can reach the target.

If you start programming before having a plan, you might find yourself in a chaotic situation. You spent a lot of time programming stuff that isn't needed at all and now you have 20 waiting tasks with unknown priorities. Chaos. The customer isn't nice anymore, you are frustrated and the project becomes more and more complicated.

In cases where the possibility of getting a good spec is low there's a project management style that has to be considered - the chaotic one.

The Chaotic Project Management

1	In the beginning God created the heaven and the earth.
2	And the earth was without form, and void; and darkness was upon the face of the deep. And the Spirit of God moved upon the face of the waters. Genesis I, 1-2

Bring the customer to your office for a couple of days or go sit with him in his. Define short tasks together and to them with his constant observation. The customer should understand that for this matter you function as his 'hands' and to the actual programming but what will be is what he asks.

Don't think about performance or beauty of code. Don't think about good DB structure, think about getting it done.

This project management style gets results very fast but it is pricey and demands great patience. It should only be used when you know you can't go a step forward in the project because of lousy communication and bad specs.

It should be done only with customers you have intimate relation with and are ready to go into this adventure with the price it demands.

Many clients don't understand what project they wish to have. This project management style is all about getting to know the project. It's about managing something that has yet been formed ("without form and void").

After a while, you'll have a clearer picture of what the project is and so would your customer.

Now will be a good time for both of you to write a good spec and manage this project in a more conservative way.

http://www.bartleby.com/108/01/1.html#S1

How to form a team, part 1

Since I started attending seminars with the great Italian coach Patrizio Paoletti, I have been trying to discover the keys that stand behind success stories. Whether it's a small change of habit, the way of a poor man to richness or helping mankind.

Last week I came across such an idea which I sense has more to, than what I understand and will present here.

When you start a project you either do everything by yourself or you take all the decisions by yourself. Either way, all responsibility is yours and all the success and failure too.

(during this post, you are BO)

After a while, you gather up a team with different skills:

This time, you are still the manager of the project but you are also a programmer. You now have more responsibilities under the high responsiblity of "Fulfill the project's goals":

1. Make the team co-op toward success.
   
2. Responsibility for Claudia's quality of work.
   Claudia is a less experienced programmer than you and thus you have the responsibility for her current work and for her growth and evolution as a programmer.

After a while, you hire more:


You no longer program but you are still managing.

Derek, Cindy and Joe are the most experienced experts in their fields and thus each of them has the cross-responsibility for his field. Tom for design, Derek for QA and Joe for programming. They are Field Managers.

Paris and Dave are project managers you hired and have the responsibility for each project's success. They are Project Managers.

You, however, have the higher responsibility for Paris and Dave success in their duty and their improvement.

What is the third dimension of this Matrix? Will.

Each person in this matrix has a skill that for which he was hired: Programmer, Designer, QA or Manager. Each person in this matrix has a level of management skills, hopefully the better managers actually get to hold this title as Project Managers or Field Managers.

The third point that each person in this matrix relies-on is his will. Motivation, higher goal or quest - the reason for which I do what I do. Whether it is in order to feed my family or to fulfill my curiosity of the profession, I must be motivated. Yes!!!

Kudos to Koby Menachemi for this insight


...and now to something completely different... Jovanotti -

Standards VS. Performance

Today I had to create an XML with ~ 7000 records.

The first role looked like this:


Controller
def all_articles
@articles = Article.find_all
render :layout => false
end

View - articles.rxml
xml.instruct! :xml, :version => '1.0'
xml.root do
xml.articles do
@articles.each do |article|
xml.article do
xml.id article.id
xml.title article.title
end
end
end
end


The size of the XML was ~ 800kb and it took 7 seconds to render.
Horror, ah?

The truth is, after thinking, I don't really need an XML in this specific case. All the data is going to be read by a JavaScript that I can modify to get any format I like.

The solution:


Controller
def all_articles
ActiveRecord::Base.connection.execute("SET SESSION group_concat_max_len = 999999999;")
@articles_big_csv = ActiveRecord::Base.connection.execute("select group_concat(articles.id,'>',articles.name SEPARATOR '<') from articles").fetch_row.first render :layout => false
end

View - aricles.rxml
xml.instruct! :xml, :version => '1.0'
xml.root do
xml.articles @articles_big_csv
end


The output of "select group_concat(articles.id,'>',articles.name SEPARATOR '<') from articles" is in the format of "ARTICLE ID>ARTICLE TITLENEXT ARTICLE TITLE..."
(I can use the "<>" as separators since I dont allow them in an article name; else I could use any sepeartors I like)

Later, on the parsing JavaScript side I will split the string by '<' to get the rows and each row I will split by '>' to get it's columns.

The size of this output is now 200kb and rails can render it 11(req/s)

(...if you are lucky and your server gzips everything it goes down to 80kb)

What did we do?
1. Smallest size: we didn't use XML standards but a simple primitive string with separators.
2. Fastest tool: we did all the work in MySql which is much faster than Ruby.



Kudos to Roman Krom for the 'let sql do the work for you' philosophy
Kudos to Boris Peterbard for teaching me the group_concat magic

Not Running

It's been a week since the last time I ran.

Last friday, December 28 2007, I woke up at 6:00am and went for a casual morning run with Arik, a dear friend from work. I already felt a bit dizzy and it was very cold but we ran anyway, a bit slow and with a Fleece I ran for 41 minutes at 156 average heart rate.

When I got back home I cleaned the house and by 1:15pm I fall to bed and slept until 4:30pm.

Saturday already felt worst and Sunday I was already sick.

It's been a week since the last time I ran.

I spent more time in bed and in-front of T.V. this week than any time before in the last 2-3 month.

Except for feeling bad and weak this week, the other expensive "price" I paid this week was of mental slowness. I already watched it before that when I run my mind is in "better shape" and that I can think much clearer but this week it really hit me.

At the end of each day I try to focus and in my head scan over the day that passed, this week it was very hard. Every-time I tried to recall the day that passed, everything was far and faded.

Today I already felt better and got back to regular work day in the office. I was restless and kept chewing things throughout the day. My mouth needed something to play with.

Weeks like this one are the reason I always return to running. It clears my mind, cools my heart and relax my body. After running I can think clearer, I am much more calm and I am not as irritated and annoyed as usual.

Next Thursday I will run 10 km at Tiberias Marathon.

* If you are a hebrew reader, pay a visit to Or's blog