Many people in the so-called entrprise do not take what I do seriously. There are two trends that I find silly. First, there is the plethora of books that promise that you can become proficient with any computer language or technology in just 21 days. Give me break! Read what Peter Norvig had to say in a very good article entitled Teach Yourself Programming in Ten Years.

The other trend is expensive training that cannot possible provide much value. Training dollars are being wasted. There are companies who send employees off on four day courses to learn how to program in .NET, for example. These courses can cost $2,500 or more per person. What can you learn in four days? Really? One such course actually states: “Prior programming experience is helpful but not required.” Again, give me a break!

As Novig writes: “There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music.”

Person A: “He says that he wants a blog.”
Person B: “A Blog!? Have blogs been approved?”
Person A: “Wikis have been approved. We can give him a wiki.”
Person B: “Are you sure? You said that he wanted a blog.”
Person A: “He SAYS that he wants a blog. Let’s give him a wiki and tell him it’s a blog.”

Some people just don’t give a FLOSS. Lord love a duck!

Everything will be fine, they seem to believe, as long as I have a record of the tasks that have to be performed and an understanding of how these tasks depend on each other. Nothing could be further from the truth. The GANT chart is just the beginning.

A GANT chart is a comforting tool because everybody understands it. A project manager can quickly show where the project is stalling, and show the impact of the stall on the deadlines.  A work breakdown is NOT a plan.

The following analogy may make this clear. If I gave you a grocery list,  and I asked you to buy me some food, you might have trouble completing the task. You may not even know where you can buy the food I need.

When you return with canned peas, I might have to explain that I really needed frozen peas. I might wave my recipe in your face and fault you for getting the wrong type of peas. As a frustrated project manager,  I might never realize that I never shared my recipe with you before sending you out.

In the simple example I give above, the list tells a project manager what he has to plan, but it is not a plan. Many project managers stop when they have their list. They have something to say for themselves if the people they report to ask them how things are going. That is all that matters. This approach is insuffient.

Two and half years ago, I worked on a project with a tight deadline. My manager took care of ordering food for members of the team who worked late. She organized rides for people who depended on public transportation. She never started by asking us how things were going, but she asked us what we needed.

She understood that overtime was necessary, and she agressively removed any barriers that would have made it hard or unpleasant for us to work late. She motivated us to work hard by staying behind with us, and she even brought us coffee. Thanks Lan!

She provided input when asked, but otherwise she stayed out of the way and waited for her scheduled updates. She asked for estimates, and held us to them. She always said thank you. She gave us the credit even though she deserved a fair share of it herself.

If a requirement was unclear, she led the charge to get us the answers we needed. She never left us hanging. Microsoft Project was used to communicate and track our progress, but she planned based on the chart. The chart was not the plan.

When we were going to deploy a new database, she asked the following questions:

1. Do you have access to the server?
2. Do you have the passwords?
3. Is there an approval or a review phase before the database can be deployed?
4. Who are you dealing with in the database group?
5. What are the risks associated with this deployment?
6. How can we be proactive to avoid these risks?

Tasks on a todo list tell what you have to plan, but the list itself is not a plan. Planning and preparing start with the task list.  It should be clear that is does not end withthe work plan. Here is another project management resource you may find useful.

To protect the guilty, I will mention no names, but I will state the following.

1. Do not just assign deadlines. Ask developers to plan and map out the work and provide estimates.
2. A todo list is NOT a proper plan.
3. Manage people not lists.
4. Build a team, and the software will build itself.
5. Screenshots are not requirements.
6. Developers need to understand the requirements and the business to do a good job.
7. Quality is not an accident, and it is not the work on any one person.
8. The fish rots from the head.

I want to speak to the first point today.

A team will rarely meet a deadline that was set by a project manager who has not asked the team for an estimate. For one thing, the date is meaningless because, at best, it represents some managers best guess. As a group, developers do not respect uninformed opinion, and that is how they regard dates that are picked out of the air.

It is difficult to motivate developers to meet these dates if you disregard their expertise. When developers are treated as replaceable cogs, you can see the lack of faith and commitment on the faces of each developer at every status meeting. Nobody speaks up.

Members of the team share neither speak about enthusiasm nor doubt. They come in, do their work, and go home. Apathy rules the day. As I have heard one person say, “Government cheques don’t bounce. That’s all that matters.”

Basically, developers need to buy-in to the deadline. When I provide an estimate, it is a matter of pride to accomplish the work in the time I have forecast. I have not excuse and I know it.

Many of the managers I have dealt with in my recent government work have not wanted to even ask the question. They believe that developers, especially consultants, will pad the estimates. Therefore, they provide a due date, and assume an adversarial stance from the word go. The work often takes longer because they micromanage or change the project plan to make up for lost time.

In my next few entries, I want to reflect on project management on some of my recent projects. For useful information, and real insight into project management, visit the Project Management Hut.

While I was there, Terry French, team leader of Canfor’s e-business effort,  expressed an opinion. I am paraphrasing after years have passed – if I do not get it right, I hope Terry will forgive me: “You code as if JavaScript were a programming language.  It is not. It’s a scripting language. It’s great for providing simple form interactions, and validating fields on submit. That’s it.”

If this blog were a trashy daytime TV talkshow, it would be one of those look-at-me-now shows. You know the kind: people who were unpopular in high school, but who have made good, confront their tormentors. Terry was a great guy to work with, but on behalf of the much maligned computer language, JavaScript, I say: look at me now!

Server side JavaScript is making a comeback.  But, wait, there’s more.  JavaScript programmers now get to deal with sophisticated concepts such as currying, callbacks, closures, array comprehensions, and test driven development in JavaScript.

And then there are those lovely libraries: JQuery, Mootools, and YUI, just to name a few. JavaScript has come a long way. What do you think of JavaScript now, Terry.

If you are interested in Javascript, check out Douglas Crockford’s videos on JavaScript at Yahoo Video.

While you wait, here is some interesting and extremely useful information about Nginx, a beautiful little web server I am falling in love with. I use it to run my Django based site, using FastCGI. If you are getting ready to setup Nginx, this is a great source of information. Nginx (prounced engine X) is fast – give it a try, if you are curious.

I will probably say more about Nginx in months to come.

So far, in tutorials I wrote in November of last year, we have seen that Jython allows us to write Python code that uses Java libraries, such as DB40. I altered the standard DB4O Formula One tutorial using Jython instead of Java, and showed that we can persist and retrieve objects using this technology.

I also mentioned that Django, a Python based web application framework, also runs on Jython.

Which leads us to this entry, where I will start thinking and tinkering to find a way to use DB4O with Django/Jython rather than a relational database.

I am doing this for fun, not for profit. I am not an expert with any of the technologies I am using. I stand in awe of the very talented open source programmers who precede me. I hope to learn as much as I hope to teach and share what I know, or think I know.

Persisting Objects:

In my previous example, I created Plain Old Java Objects (Pojos), and created a JAR. I used the classes in the JAR to create the objects I persisted using DB4O. I have since decided that this is not desirable. I think this creates a barrier to Python programmers who want to use Django, Python and DB4O togther.

Therefore, I have resolved to persist Python classes by providing the means to automagically inspect these classes and generate the JAR files. I shared these thoughts over a month ago.

Before writing any code, I just want to reflect on the task at hand. Let’s gather our assumptions.

• For every Python data type, there is a corresponding Java data type.
• A “simple” object is based on a class that contains primitive types only.
• A complex object contains other objects, or collections of objects.
• We may need to make two passes to persist objects – first simple objects, and then complex.
• A class contains an implementation as well as data, and we want to persist both.
• If we change the definition of a class in our project, we need to think about what happens to our previously stored objects.
• Our Jython classes must inherit from a single class only, or we will not be able to produce an equivalent Java class.

In Django, we define models, and then use a command (python manage.py syncdb) to generate the corresponding database. The database is created automagically, based on the settings in the settings file (settings.py). The model is able to perform basic operations to create, read, update and delete objects (CRUD).

We want our DB4O objects to behave in the same way – as much as possible, we do not want to violate the expectations of Django programmers who have used Django with relational databases.

In my next entry, I will try to write code that creates a Java class based on a Jython class and saves it in a file. I will keep it simple to start, and the code will evolve as we go.

Our first model will be simple – a class with a few attributes of various types. The output will be a class files – we will not worry about creating the JAR just yet.

Once we have produced a simple class file, we will produce class that make two passes and resolve inheritance issues as well as contained objects that inherit from previously defined classes.

Code to come in a day or two.

I live in Ottawa, Canada. We are currently experiencing a bus strike – traffic is a nightmare. Some people are reporting that it it is taking up to four times longer to get to work and home. My experience is similar. Combine that with the Christmas season, and my time for blogging and coding is drastically reduced.

Still, I can see that many of you continue to visit. You are eagarly waiting for continued information on my progress with DB4O and Django running in Jython. Last month, I received blog visits from 411 cities in 69 different countries.  I am proud to report that 57% of you are using the Firefox browser – only 21% are using Internet Explorer. As an aside, I was surprised to see that 6% of you are using Chrome.

So, my friends, if you can forgive me – I will contnue the work soon. And, I am sorry for not blogging. All the best. I am not writing, but I am developing and tinkering – the work continues.

If you like what Java has to offer in terms of class libraries, but you like the Python language and its idioms, then Jython is the best of both worlds.

To prepare for my next installments on Jython, Django and DB4O, read about introspection in Python.

These seven habits for developing secure applications target PHP developers, but they constitute good advice for you, even if you are working in another language. Take heed.