I hate wasting time. If you have time don’t wait for (more) time, that’s one of my favorite savings.When I started working I had a small commute by car and some time got wasted waiting for the traffic light to become green. So I started reading books in those waits.
With my MS-Windows becoming slower and slower at startup, I decided to spend the waiting time reading books. At work I started a copy of “Slack” by Tom De Marco. Being a book on efficiency I found fitting to read it in recycled time.
If you work in software development (or if you are a “white collar” at large) you ought know who Tom De Marco is. Or, at least, you should have heard about the book he wrote with Timothy Lister – Peopleware. This is one of the most referenced book, almost every book on project management written in recent years quotes Peopleware.
Back to Slack, this is a book intended to be read in a short time to convey good an bad practice about efficiency, innovation and risk taking in today’s organizations.
The author states about an hour and half as reading time, I guess it is somewhat more even if you read from page 1 to the end at the same time (and not scattered over a couple of month of PC boots), nonetheless the thought-provoking stuff is very dense. Chapter are short and almost everyone made me think.
It is possible I will write a resume of it in the future, but I strongly encourage you to read by yourself.
Tom hacks through myths trying to grasp what is needed by an organization to survive in times of change and crisis. First myth to fall is the one of total efficiency. Total efficiency means total rigidity. An organization that maximizes efficiency cannot withstand change because lacks of the buffer and the spaces to react to change and adapt.
Then he digs through the (wrong) assumptions about making the organization more productive – pressure, competition, fear and so on.
Eventually he bashes the Management By Objects and illustrates what really means to deal with risk.
For example planning should be an estimation and as a such should offer a range defined by: cannot complete before X and surely completed after Z, with a best estimation at Y, with X <= Y <= Z. Now that’s a planning, that’s quite different by setting a goal. From my experience, someone defines a planning, someone else carves it in stone and says that’s the goal. This way of operation ignores the risk, ignores that an estimation is just an estimation, not a commitment, and it is just a sure way to have a delay on the completion. In fact, even if the most likely date (Y in the example above) is taken, this is usually achievable only with a probability of 33%.
De Marco also marks “Management by Objectives” (MBO) as “don’t”. I already read about criticisms at MBO, but more about the bonus system rather than objectives by themselves. De Marco states that it is hard, if not impossible, that the defined objectives for employees lead the organization toward company objectives. Also in a time of changes it is hard to hit an objective even if the actions taken are excellent for the company.
I found this particular opinion a little forced on software development. I think that an objective and bonus scheme over the course of a project, if properly done, could be helpful. Maybe MBO is just crap if applied to vending or other areas.
I liked the book a lot and I think it is not just for managers (regardless of their level). The more widespread the ideas here contained the better the life of fellow programmers.
Requirement baseline
I thought that by nowadays two main consensuses had been established towards requirements. The XP-ish “waste-of-time” school of thought that pretends this stuff belongs to NASA and similarly priced development and clearly are NAH (Not Applicable Here). And the “we-need-them-right” school of thought that believes in properly written and managed requirement documents.Of course, I am biased, I belong to the second school since I don’t buy the XP gibberish and I am a firmly believer that a sound methodology may not be The Solution to all software development troubles, but it is surely part of it.
So I am a bit surprised when I received a 35 pages requirements document that’s actual crap. Joel Spolsky wrote a sort of basic requirements for requirements in four parts. Well below is my list. I don’t want to compete with Joel (really, do read his post, even parts 1 and 2 and 3, it’s worth), but mine is shorter and should fit even in a tight schedule should you be requested to write specifications.
Think of it as a baseline rules of thumb:
- start by describing the system to which the specification refers. What it does, which kind of existing systems do more or less the same.
- don’t go ahead. These are specification, not software design. Leave out the “how”s.
- define every acronym you are using. Not everyone knows even the most basic acronym, left out the more exotic ones (I’m still wondering what “TBP” does mean). Also define terms that are meaningful only for those who already knows what you are talking about.
- list requirements in a way you can refer to them. Number them, or better use textual tags so that you can refer them in the same document or in the documentation that is following.
- Don’t use the following words: “some”, “etc.”, “good”, “bad”, “fine” and the ellipses. The idea is that you have to be precise and define the entire system without leaving open holes.
- use a spell checker. It’s easy, every modern Word Processor has it, just switch it on and fix the words underlined with the red snake (you should really do this for everything, not just the requirement document).
- re-read everything. People is going to read and work on that document, just re-read and fix, iterate until you don’t fix anything.
As trivial as they seems, all these rules were broken at least once in the document I was handed.
Software project failures
Yesterday I stumbled upon an article about why software projects fail. Though hardly you can find any surprising claim while reading, it is nonetheless a quick paper you can hand over to your colleagues and/or managers when trying to enhance the chances for a successful project.What I find quite interesting is the table near the beginning, the one titled “Project Challenged Factors”. What draw my attention is that the “other” item weights more than each other single entry in the top ten. In other words the causes for challenging projects are so widespread and so equally important that there is no a main culprit.
We programmers are working on a so complex and delicate mechanism that any one in hundreds of factors could drive the entire stuff crazy. On the other hand the number of variables involved is so high that it is not possible to shot at one target to likely ensure project reliability.
Take software requirements for example, (missing or incomplete accounts for a 12,3%), while I am not advocating about entering a project without them, it is clear that in some circumstances the lack of such documents is not dooming per se. Take for example an expert team that knows all the ins and outs of the domain and has a crystal clear idea of what is needed. In this case maybe the project could get along with no SRS.
So one might be tempted to strictly follow every “best practice” to minimize the risks of a failure. But this is not likely to work either – every practice has its cost and some practices (take the “code review”) are extremely daunting.
Therefore is all a matter of balancing, picking the right decisions, having good reflexes and willing to occasionally work harder to fix what has gone wrong.
Following this line of thought the best insurance you can have for your projects is an experienced and well jelled team with: a) an experienced leader, b) a good success history. This isn’t rocket science either, you can find similar assertions in many software project management books (Peopleware is the first coming to mind).
On the other hand projects keeps failing. This leads me to two considerations, first is that even with the best premises a challenging project could fail – we have to accept this for today’s projects and try to minimize the failure impact. Second how is changing the failure rate in time? The first study quoted in the article is more than 13 years old! That’s a huge time in software industry.
2nd level outsourcing
This is funny, I was joking last Saturday with two friends of mine about the fact that outsourcing to India is no longer convenient and that Indians may outsource tech-jobs back to US, and this morning I found this news: Indian Software Firm Outsourcing Jobs To US. I hope this could reverse this odd trend of relocating tech jobs in the far east, and provide for a better distribution of the wellness in the world. A friend of mine told me that Indian programmer salaries are low for young and/or inexperienced, but rise steeper when compared to western programmer. In other words inexperienced programmers are cheaper in India, while experienced programmers are cheaper in western countries (while being more expensive than inexperienced programmers everywhere :-)).
And Italian programmers are cheaper than other western countries’ programmer because Italy has the lowest salaries among the industrialized countries of the EU. That’s to say it is viable and worthing for a US company to outsource tech jobs to Italy. I just recommend to provide their management because local workforce has serious trouble in grasping tech-projects management 101.
Antipatterns at work
It is an odd sensation. I am puzzled about some decisions that are quite unanimously recognized in literature as bad, or, if you prefer the buzzword, as anti-patterns. Forests have been sacrificed for books on the matter. Given the current (poor) state of the planet I would urge management to read them, not just having them to preserving their libraries from dust.
You have this project late, the customer is coming screaming at you because you didn’t made it for the milestone, the product is still alpha quality when it ought be on the shelves. Sounds familiar? If not either you don’t work in any technologically advanced sector or you have been unbelievably lucky (or good… or both). So it is clear that the project needs extra time to achieve the goal set. I understand that there are contracts and politics involved, but for the sake of the project there is just to plan and move the milestone ahead WITHOUT adding new features. Leave them for another project. The customer could be disappointed from this refusal but she will be a lot more disappointed when you’ll told her that you didn’t made it another time.
Disclaimer: I have to be honest, this is not my project, I don’t know exactly what has been agreed on, the only thing I know is what a coworker told me in about a single line: milestone postponed, new features added. So basically I don’t know what I’m speaking of.
Behind Closed Doors
According to the Dilbert’s rule everyone gets promoted to his/her highest level of incompetence. In the computer programming field this is dramatically true: brilliant programmers, after few years or less are turned into management. First they are promoted to lead programmer roles and, if they have the double DNA, they could grow in the management career. Why is required a double DNA? Because programming has to do with machines, while management has to do with people. And people tend to get upset when treated like machines.
Moreover programming is about reaching a goal worrying about the smallest detail, while management is about setting goals for other people letting them sort out the minutiae.
When I became a lead programmer I hadn’t a clue about this and no one cared about telling. I just was asked about when my team would complete the application.
The project was rather successful, but it could have been far better. That’s why, with the next job I started reading books about management.
This book is the first I read about the next level: it is about managing lead programmers. The book is simple, easy reading and well structured. It is not as brief as “One minute manager”, but is very concise; you can read it in a couple of days. More than once I wished that my boss had read it.
The authors use a fictional character to make their points and providing a running example. This character is a just hired manager to which six lead programmers are reporting and who has the goal of reducing costs and increasing the value of his departments work.
Authors propose a number of techniques for managing proficiently. As implied in many parts the job of the manager is to facilitate the work of people reporting to him/her, removing obstacles and providing support.
One-to-one is a meeting held weekly during which the manager meets just one lead face to face. The meeting lasts about one hour and the manager gathers information, provides supports, sets skill development goals and coaches the lead.
Team meetings are held weekly too and the goal is to provide integration between teams, exploit synergies, and prevent inefficiencies.
Coaching is to help leads to develop skills that are beneficial both to the company and to the lead herself.
The manager is encouraged in:
- Assess attitudes and interests of the lead teamers. It doesn’t make sense to force someone to do something that she’s not interested in;
- Managing by walking around, that is taking some time just to wander around in the teams to taste the mood of teams and the rhythm of work;
- Enabling the lead team jelling;
- Give feedback immediately. Do not wait to the next event (end of week, yearly review or the like), people need to know if they’re doing right or wrong immediately.
- Delegate
- Acknowledge good work
The book also instructs the reader on influencing and resolving contrast. Influencing is for the best of the influenced one, it can’t work in the long term otherwise. Resolving contrast is much sticking with facts and trying to put in the other one shoes.
The planning is dealt with a weekly resolution for a couple of month. It is defined by leads and their teams and can be arranged in terms of priorities or delegation by the lead meetings. Beyond two month the planning is very rough. Also the planning is suggested to be kept is a meeting room in the form of a panel with sticky notes so that it is clear for everyone that it isn’t carved in stone.
Problem solving techniques to employ in meetings are proposed. Many of them relies on the brain storming techniques with some modification to ensure that everyone (even shy people) could participate.
The book contains a great deal of tips and aids to do management things. Usually there is an example, the motivation, a ‘to-do’ list for the technique and then there is a recap frame at the end of the book.
I highly recommend this book to all those managing lead programmers or the likes. I still recommend this book to lead programmers since many of the presented techniques are still applicable in the smaller context and can be helpful to back-coach the manger in a more sound behavior.
XS – eXtreme Snack
I’d like to share a couple of thoughts about an aspect of XP – snack food and something else. According to XP in the development room there should always be plenty of snack food. Also Kent Beck in his Extreme Programming Explained – Embrace Change (you can read my opinions about the book, and the summary I wrote in Italian) recommends that for celebrating a milestone or some important achievements some food should be feed to the team.It happened sometimes to me to offer some food to the team the day after a milestone. Always I did what I felt, but I’m a bit dubious about using this as a technique for keeping the morale high.
If the milestone was difficult to reach and the team did some really hard work, then I think it would be correct for the ‘gold owner’ (to use an XP term) to give an amount of money (maybe small, but not too small to be insulting) to the team. So if you really want some food you can buy it ;-).
I mean using food as a compensation recalls quickly laboratory mice. “you find the exit of the labyrinth, good boy, here you are your piece of cheese”.
In the same way I’m against using T-shirts, games and other gadgets as milestone bonus. Not that I’m against receiving this stuff in general (it’s good to create a corporate spirit), I’m against the idea that my hard work, doing something difficult on time, what I brought as an added value to my being a software engineer, is rewarded with a gadget. It’s not professional. It would be like tipping a waiter for an excellent service with food rather than money.
And in fact the professional aspect of our work (programming and game development in general) is hardly recognized. I think that we who work in this field, should be the first to promote professionalism, letting our enthusiasm cooling down if needed.
One of the obstacle is that it is difficult for people to understand what it takes to become a good programmer. Also today, with many advanced development environments and tools, it is easy for many to write some automation and calling themselves programmers. As I recently read on DDJ magazine, this would be like that anyone who can keep a surgery knife in his hand and knows something of anatomy could be called a surgeon.
To close it up I would say: Real Programmers don’t accept food as compensation 🙂 (and watch out for too young surgeons).