Lessons from a pyramid foreman
A few thousand years ago in the desert of Giza, the construction of one of the most ambitious constructions ever was initiated. Hundred of thousands of workers were involved in what is today know as the Pyramid of Giza which remains an eternal monument of the creativity of the human race.
A time trip
Let’s assume that we have a time machine allowing us to travel back to time and experience the hard labour that was involved in the Pyramid making, from first hand.
Going to the quarry, we can see a huge group of slaves assisting hundreds of mules, moving a huge boulder closer to the pyramid, following a very brutal and laborious moving methodology!
Many a little makes a mickle
It goes without saying of course, that such a titanic project, needs some sort of a great management… Pharaoh’s executives and rapid development consultants, accomplished their mission by conceiving a brilliant plan, that they believe that will not only be applicable for the specific task but can be applied to any kind of human activity, ensuring quality results, in very short periods of time! Every dawn, the general manager is inspecting the progress of all the teams, measuring the distance covered since the previous day; who made the most progress, is receiving a small bonus for his productivity in weekly basis while the bottom five performers are whipped in public view. By doing so, both the foremen and the slaves, are always motivated and eager to produce and there is a great level of competition among them, that naturally improves the final result!
Each boulder travels anywhere from one to two hundred meter daily and takes approximately anywhere from three to four months to reach the location of the pyramid, where the masons will undertake it while the conveyors will be entitled to a full day of rest before they repeat the same process again.
A strange new comer to the camp
What makes our trip interesting, is a new former that arrives to the quarry with his team of slaves, seeming a bit different that the rest of his colleagues.
Instead of immediately put his crew to work, he spends an entire week doing nothing!
He spends the whole day under his tent, scribbling in rolls of papyrus staying while periodically is sipping instant iced coffee to keep him alert!
Meanwhile the others are busy, following their usual routine during the day, while the nights are wondering about this new guy and what he really is trying to do.. The stranger seems so lazy and inefficient and without a doubt he is the worst foreman ever seen in the face of Egypt!
When a manager was asked by a foreman about the newcomer, he was told, that the guy is probably out of him mind, but there is very little they can do about it, since he appears relative of the Prince and probably blue blooded himself. He seems to enjoy a lot of trust from the senior levels or management who apparently are completely deceived by him…If it was up to him, the manager adds, this weird and lazy guy would have been ordered to decapitation serving as an example to everyone…
Foremen caught by surprise
Next day, things are getting even more strange! The weird foreman, takes his team and leaves the camp, heading to the forest located to the exactly opposite direction to the pyramid!
A few weeks are passing and by the time the small talk about the crazy foreman is about to stop, he returns to the camp carrying a huge load of logs, pulled by an army of mules and slaves…Nobody seems to understand what is going on!
Upon his arrival, his team builds wooden ramps and gears and after a few failed experiments, he manages to find the way to use the ramps, making it easy to load a boulder in a wooden platform while using logs beneath it, he converts the platforms to some kind of a wagon having the logs as its wheels!
All the pulling is now conducted by the mules while the workers responsibility is now only to switch the logs as the platform moves ahead carrying the boulder…
At this moment, he starts carrying the first boulder, which is delivered to its destination after only five days, a huge improvement over the three months the other teams needed for the same task..
What happens afterwards is that all the other teams are adopting the same method, the building of the pyramid is becoming faster and every one is happy! As our time trip ends, the strange foreman has become one of the top consultants of the Pharaoh himself while his old colleagues still are pushing stones in the desert, using of course the new method that has become the new standard of operation!
Quick coding and frequent releases
The story of the pyramid workers has a lot to teach a contemporary software developer and managers and can be used to challenge some of the widely used managerial doctrines, like delivering working software often, having demo-able changes in the end of each development iteration and the need of trust among the several layers of management among others.
Two of the most common misconceptions in software management are be found in attempts to measure development speed and in the concept of frequent incremental releases as the means of accumulate business value, each of them delivering some small amount of tangible changes to the client.
Software is abstract and intangible and unless you are a programmer who can understand implementation details, it is really difficult to appreciate code improvements and realize how they are related to business value and the overall improvement of the platform as a whole.
The manager’s case
Software projects have been notorious for their increased probability to never complete or to greatly inflate their original time lines; given the fact that programmers represent expensive labour and estimated cost cannot be estimated accurately, managers are reluctant to engage to new commitments having the fear that they will fall into an infinite loop without much control of how to get out of it.
Since non technical managers cannot read code nor can they understand software design, they have find out that one way of been on top of their platforms, is to insist on tangible changes that can be demoed based in visible user experience behaviour while they remain reluctant to accept any other non visible concept as any kind of a progress.
This attitude is eventually passed to developers, who soon realize that their annual review will depend on how fast they can deliver “working code” with visible feature extensions and adjust accordingly by adopting a rather mechanical style that consists in “quick and dirty” extensions that can keep their managers happy.
Drop away code adds to the business value
What seems to be missed by the frequent releases of working software approach, is the fact that thinking, learning and experimenting, add value to the business even if they are not necessary reflected directly to a delivered product.
Creating any kind of quality solution is synonymous of a lot of thinking and more than this, with failures in a lot of experiments.
Thomas Edison quote about his failed experiments:
“I have not failed. I’ve just found 10,000 ways that won’t work.”
proves that burned light bulbs or throw away programs consist a necessary part of the final product, that will eventually deliver customer value.
Software needs not to be confused with any kind of an activity requiring manual effort and brutal force; writing code is not the same as building a brick wall. The later, representing a very mature activity can be easily managed by counting the number of bricks used every day, the former is impossible to judge and measure until it becomes a production component and are only its users that will make the final call about its quality.
Similarly to the pyramid example, in software development, there are many cases where real progression, remains invisible to the client for some period of time until it is materialized to a concrete solution.
Frequent releases: What might go wrong
The quick coding – frequent release approach seems to work well in the sort term, especially in maintenance projects which perform small alterations to the code base like adding small features of fixing known bugs. It is a matter of time though until system becomes very complex and fragile; usually at this stage the code, is going to be touched by many different hands, as developers are notorious for the high rate of turnover thus the number of different coders involved combined with the mentality of quickly delivering working components are hurting the compactness of the solution, which even if it was originally written well, it degenerates slowly to a construction reflecting to large scale the way it was created, meaning the tight deadlines and the desire to sacrifice quality over quick and visible deliverables.
Projects that are driven by this kind of a management, very soon will reach the point where a radical reverse engineering or even complete rewrite will be required in order to keep the company competitive in the market.
High quality, is the product of upfront thinking which is followed by careful implementation; reimplementing parts of the solution several times, might be our best choice in some cases.
Following this approach, the developer might seem like the pyramid foreman, who spent weeks having no real progress to show, at least by the standards of his peers. In software, the solution is conceived as an idea and in most cases it needs some time until it reaches a point where some tangible functionality can be shown to its users.
It is quite possible for a developer, to spend a full month of low level work, having no immediate impact to the user. This should be more preferable over some small coding patching, assuming the time spent in infrastructure improvements will reveal their value in the future as the platform will be maturing.
A high quality platform, presenting the necessary degree of code reuse, adaptability, documentation and easiness of administrator is not something that can be accomplished following a shallow way of design and and an overstressed implementation plan, having as its primary goal to meet artificial deadlines.
The requirements for an ideal software project
To apply a flexible management style, is not always a matter of a will, there are some concrete requirements that need to be available, otherwise chances are that the project will either fail or never reach its full potential. Some of these necessary requirements can be summarized in the following:
Budget
For any project to be developed in a quality manner, it needs sufficient commitment from the company that is sponsoring it and of course it needs a large enough budget.
Inadequate funding multiplies the chances of failure of any project.
The developer should be reluctant to get involved with any project that does not have enough capital allocation, unless the potential rewards appear to be extremely large.
Cases where it might be correct to operate while “short-stocked”, usually can be found on start-ups that try to come up with a solution that will allow them to qualify for more venture capital.
Talented developers
Successful Software Development relies to a great extend to the talent of the developer, which in conjunction with his experience are the main factors for the creation of a highly reliable, usable and evolve-able platform.
Influential managers
The manager of any ambitious project, needs to be influential enough, to convince the upper management about the value of the solution he is developing and also needs to have the ability to absurd a lot of the pressure, directed towards his team..
There is nothing worse than a manager who always tries to satisfy his seniors, promising things that will be impossible to materialize in the provided time or never demanding improvements for the working conditions of his people.
Trust
The most important aspect of the relation of the developer to his managers lies in the degree of trust he is viewed with.
Ideally the developer should be treated as a black box from his managers who should never interfere with any implementation the details.
It is not uncommon to our industry, for managers who do not provide enough creditability to their developers to hold them accountable in the case of any failure; such a behavior is completely unacceptable and both parties should try to clarify this type of issues from their very first meeting.
The developer needs to enjoy a great level of trust from the project manager and the senior management of the company, who will need to realize that they need to provide him with enough credit, to not have to worry about proving his effectiveness with very short iterations but he can concentrate to the large picture and the strategic vision of the company, which is what matters the most.
Conclusion
Development Progress and Business Value, represent abstract concepts, that are not easy to quantify and measure by simple criteria as the managers of the foremen used to do every day using their yardsticks; there exist many cases where both of them are concealed to some abstract form and only time will reveal their utility and benefits.
Some times software evolves with jumps and some times with short steps; it is the developer’s job to decide what kind of evolution is needed.
A silver bullet solution, applicable to any kind of a project simply does not exist in the real world; in contrary we need to maintain the right degree of flexibility and posses the necessary experience to make the right decision in regards to the specific problem we are facing each time.
