Love it or hate it, project management is a thing. It has to be there. If you don’t think it is there, you are just doing it badly.
Project Managers are a different kettle of fish. Some need to be boiled alive. Others can just dance on hot rocks. And a very few can sit at the big boys’ table.
I’m coming off the end of a rush project that was big. I had to take a customized system and add tariffs to it with about 14 days from concept to deployed. More than a little to get done.
When I started programming, I had a choice of an 8080 with a 24×80 character display, or a 6502 with a 24×40 character display.
When I was introduced to JOVE
, Jonathan’s Own Version of EMACS, I fell in love with it. Multiple views into the same file, the ability to copy and paste from different files or different places in the same file. And auto indentation.
Powerful stuff for the time.
My fingers worked will with vi
and later vim
because I played Nethack and before that, Hack. The programs had a particular key set for moving the cursor based on the key caps of a terminal type used at MIT.
The author had never seen a terminal without arrows over the J, K, H, and L keys. To give you an idea of how ingrained those are, I had to fire up vim and tell my fingers “down”, “up”, “right”, and “left” to record the keys for this sentence. My fingers know, I don’t.
Besides jove
, I learned emacs
. Emacs is my programming editor. It is what I use when I need to write a lot of code or text. With modern computers, it starts just as fast as jove ever did on a 68020 class CPU.
The problem we had was keeping track of what needed to be done or fixed. This might start off as a document, written with jove in troff
. This could be fed to different processors to create PostScript files to be sent to our printers.
Later, some of us used LaTeX for the same thing. Your “design document” was a separate file that was “fixed” before you started coding. These documents never contained more than brief pseudocode and discussions of algorithms.
As you were coding, if you discovered something, you created a comment and marked it. The two most common marks were, XXX
which meant that the code was broken in some way, but it didn’t need to be fixed now. All XXX marks had to be addressed before the code could be released.
The other mark was TODO
. This was working code but needed some features or extensions added. These did not need to be fixed before release.
In general, we used grep
to find all these markers in a list of files. It wasn’t difficult.
The small program I’m working with has some 250k lines of code. After 3 or 4 years of supporting this site, I would say I’ve looked at every line of code in the system.
Finding every marker in 4100 files across 1200 directories is a pain.
Enter Kanban
Kanban is a project management tool. The concept is easy enough to do with sticky notes and a white board or notes with push pins on a larger bulletin board.
Today, the normal Kanban has 4 columns to hold cards. The cards are labeled, “backlog”, “To Do”, “Doing” or “Working”, and “Done”.
When you create a card it goes into the “backlog” column. These are issues or tasks that have no resources assigned to them.
Once per week, there is a meeting of the workers and the project manager. In this meeting, the project manager evaluates the cards that are in the “Done” column. If they are truly done, then they are removed from the board and added to the QA project.
Cards that are in the working column stay in the working column. Cards that are in the working column can be moved into the backlog column if some other card blocks them.
For example, if you have a card that says, “Put new tire on left front wheel” it cannot be worked on until the card that says, “Purchase a new tire for the front left wheel.” Until the purchase card is completed, you can’t work on the installation card.
If there are any resources (workers/developers) that think they are going to need more tasks to work on, the project manager will take cards from the backlog column and move them to the To-Do column.
When a worker requires more work, they move the card from the To-Do column to the working column. When they complete the card, they move it to the Done column.
I’ve used Kanban in the past. It never really appealed to me as it didn’t feel any different from the old ways of doing things.
For this latest project, I used my Kanban board.
Instead of putting markers in the code, I opened a new issue. That issue just went into the “backlog” column. I could tag the issue as a bug or a feature. I could indicate that cards were blocked. It was faster to create the issues/cards than to make entries into the files and then try to locate them later.
Today, I’ll be looking through anything in the QA column and writing unit or web tests for them. I’ll also be doing a QA across the site, to add to the project board.
The biggest thing for me was the ability to visual see what still needed to be done.
Conclusion
Good tools make the work go faster.