Binary Kitchen

For those wanting to develop low-cost, hight-quality software, Szabolcs Michel de Gyurky's groundbreaking book The Cognitive Dynamics of Computer Science: Cost-Effective Large Scale Software Development is a must read. He shows how a manager - by using his principles - can create a winning team that delivers a project on time and under budget

In my previous article, I already wrote extracts from the first half of the book. This article here is the second part with more extracts and wisdom I want to share with everyone who cares about proper computer science, staying on budget and on schedule.

(a little warning: To understand this second part, you better read or know the first part otherwise you won't understand some terms or concepts)

So, enough said. Enjoy these extracts:

• The design hub approach (explained in part one) also refers to the physical architecture like your workspace. Close quarters, a big conference room in the centre and few separations like walls between segments reflect the idea of the design hub.
• System engineers are the project equivalent of capitains in a football team but doesn't always see the big picture. Above all, the system enginer doesn't have the authority to bring discipline to the meeting; he is equal among others. On the other hand, the manager-architect does and is accountable for everything.
• Good leadership and the correct organisation is the key to reduce friction which slows down the process.
• To better understand any situation during a meeting, it's far easier to look at the big picture than at small individual representations of it.
• Large projects design meetings should be held daily. Every member must understand the design completely, meaning the acceptable reality of how the thing will work (see part one).
• Senior engineers, team chiefs and other design team members meets from 0800 till 1300 hours, 5 days a week during the requirements and desing phase. During these phases there aren't any junior programmers at all or only very few, working on a prototype or on a GUI draft.
• Normally the activities of the previous day are reviewed first, then status reports of each team chief (segment) are reviewed and then resolutions are made and disputes settled with  the individuals responsible for that segment. Everyone listens. Make sure everyone understands. And most of all, don't let anyone distort the common goal. Distortions can cause days of delay and lots of money.
• In Mr. de Gyurky's view, the traditional development methodology is the safe and proven approach to getting the job done. The waterfall method is predictable and works incredibly well when requirements are known. Furthermore it goes well with the manager-architect who manages everything.
• When designing the architecture on the lowest level before implementation, include the junior programmers in the design meetings. They haven't been heard anything until that point. So invite them, make them feel they are a part of the project and are heard.
• Senior and Junior programmer also know best what's possible and know the latest trends and tools. A manager-architect doesn't, so this kind of design meeting is a great opportunity for him to learn about the latest tools, compilers, and platforms available in the market place. In turn, the younger members  of the team learn all-important lessons in technical management, design methodologies, techniques and the design process. It's important to learn lessons to avoid future costs.
• The theory is how I subjectively imagine the system will look like when it's completed; the reality is what my engineering staff and computer scientists agree to, within the constraints of the state of the art.
• System engineers often don't know how to start a project because they lack of a "Vorstellung" (German for imagination). So the manager-architect has to push his architectural vision over onto them first. This ability to visualise  a priori a design is an aptidude a manager-architect needs to save time and costs. A good leader must set the project in motion without letting the engineers in the dark.
• Like the German philosopher Immanuel Kant stated in one of his essays, the worst trait of all is the lie. After you lose your honesty, you become a person without honor. With the other terrible trait cowardice, the inability to stand up for what is right, both destroy budget, schedules, quality of product, and quality of life. A good leader never shows these characteristics.
• Good leadership with honesty is probably the most dominant factor in the successful of any project on schedule and on budget. For example the inability or unwillingness to correct a mistake will ruin it.
• These are the attribtutes of leadership:
  • Unselfishness (work hard with the team)
  • Caring for the welfare of others (make the team strong)
  • Ambition (get motivated, raise above others but not at the expense of the job being done)
  • Integrity (always acting for the greater good by rules, creating an ethical work environment)
  • Loyality (Among staff a multiplier encouraging trust, honesty and respect)
  • Knowledge (Thorough understanding what staff need and are working on enables the leader to be more effective and especially, enables him to assist design meetings)
  • Tact (Don't curse and bring terror on the workplace. Only in front of good friends you can do that)
  • Judgement (Making a priori decision depending on experience and knowledge to save time and money)
  • Initiative (Doing actions, moving on, when there are no plans nor orders by assessing the stituation correctly)
  • Bearing (It's good, a positive effect, when the physical appereance of a leader present himself as a leader in the way he walks, talks, carries on and dresses)
  • Courage (Good leaders must have courage to communicate problems upward and also can't be afraid to listen and make corrections to a bad situation)
  • Decisiveness (Hestitating to make decisions is the result of a lack of confidence + experience and thus a time-consuming approach)
  • Dependability (Reduce dependencies to others to save time)
  • Dynamic Energy (Endurance; energize the team which is a multiplying effect and be always at the workplace in a timely manner)
  • Enthusiasm (The world is full of people who only see the negative side of an issue, so a good leader must infect others with his positive enthusiasm)
  • Empowerment (free communication of ideas without fear from superiors or peers)
• Having to work more than 8 hours per day just to get things done is an indicator of poor planning, poor work habits, more stress and poor organisation. Work overtime only when an unforeseen emergency occurs.
• Having considered the positive attributes of leadership, now we consider the signs of poor or absent leadership in an organisation:
  • Loss of market share
  • Declining quality of the product
  • Good programmers leave
  • Cost overrun
  • Absenteeism (putting all decision making on hold, inability to cope with problems)
  • Hidden agendas (typical hidden agendas include the behavior of power-seekers, and the political intriguing to get to the next higher position)
  • Communication gap (make sure information isn't withheld in the middle-level by doing inspections otherwise communication gaps might continue to spread)
  • Poorly defined goals (is  the project implementation plan not well-thought-out and not well-written then the organisation won't be going to the desired direction)
  • Personal struggles (if you can't keep struggle for power among subordinates under control, then concentration among them is low and costs will soar. Like Nietzsche said, seeking for domination is in our human nature. So the trick is to control these personalities and channel their energy through persuasion, and also to develop their understanding in ethics)
  • The "Machiavellian Prince" (Machiavelli observed that Italy lost the war against France because Italian city-state struggled so greatly among each other so that wasn't enough common sense and noone was really leading. He concluded that the power to change things rested only in the hands of one superior talent which became the foundation of the field of political science. So for a project the manager-architect must make sure that everyone compliment each other as a team according to their abilities and channel everything to a common goal. That's a winning team. Avoid Machiavellian Princes at all costs.)
• Regarding to Immanuel Kant, self-respect is the will to do what is good which is also an attribute for a good manager-architect. In other words: If there is a way to increase the quality of a product, lower the cost, and shorten the delivery schedule, the manager-architect will see to it that it is done. It's a clarion call to all managers to apply pure ethics instead of collecting flying miles or playing golf in New Zealand.
• Avoid characteristics of a dictatorship and let every subordinate speak his professional opinion freely. Because information must flow. A missing key element of information could break a project.
• The manager-architect is also required to provide a safe working environment without narcotics. Employees high on drugs have a staggering impact on cost and product quality. Wine or beer is ok  but heavier drugs can cause  a Dr. Jerkyl and Mr. Hyde syndrome making it more difficult for communication destroying the workforce from within (Furthermore Mr. de Gyurky mentions that the fraggings in Vietnam he has seen with his own eyes when leading his own platoon were not done by clear-headed people; they were done under the influence of narcotics).
• Management is in some respects the equivalent to what we refer to as leadership in the military. The good manager rarely finds himself reacting to conditions he has not anticipated (means he's  few months ahead and has studied plenty of scenarios) and is always the initiator of action based on the information he receives from his staff and employees.
• For a manager, motivating a 10-person team is difficult; to motivate 200 or more requires enormous reserves of energy causing more stress. Sport is a good mean of dealing with stress and to free your mind for the next day.
• For a manager-architect there is little time for travel. The reason you have a deputy or system engineer is so that he can do your traveling. They know as much as you (sufficient reality) and can solve the problem there where they are travelling to. They only lack one attribute the manager has, and that's the power for paying salaries, hiring, firing and making important decisions. In rare cases, when conflicts between deputy or system engineer need to be solved, the manager-architect can travel. But the manager-architect should always be present at the workplace and make daily decisions there.
• The number of frequent-fyler bonus miles on a manager's account is directly proportional to the cost overrun and schedule slip of his project.
• There are two types of decisions: Drawing carefully on our past experiences is called  an a posteriori decision. If we make a decision based on an incomplete set of data (knowledge or personal experience), it is called a priori decision, excluding reason but based on your very own concepts and mental picture your sensors are generating.
• Even Mr. de Gyurky doesn't always trust his own a posteriori decisions because these are based on a judgement formed as a result of the synthesis of all experieneces drawn from the individual's experience "database". Only with little luck and smooth communication making sure nothing is left out, that database (Kant calls it "Wells of experience") is sufficiently full for making an effective decision.
• Therefore when you make a posteriori decison, make sure you assemble all the relevant people who have generated an acceptable reality with you for a relatively sound decision. In other words, having agreed on a such an acceptable reality fewer mistakes are made in decisions and costs for the project are lowered.
• The a priori decision, however, bypasses that experience database and is more prone to mistakes but is a great shortcut to save time and cost. Only those who have the concept very clearly in their head can make such decisions.
• Never  select people because you like them, their attidude,  or above all someone who is pleasing. When hiring staff, look primarily at academic and technical qualifications, experience, completed projects etc - and make sure you have tested their skills yourselves. It's easy to cheat nowadays.
• It's okay to have high qualified staff. Because a highly proficient team has three times the productivity of one that is not expert. This results in low-cost software, high production and quality production on the cutting edge. And this enables you to hire junior programmers and apprentice them to the senior experienced ones which will save lots of money in the long run.
• Sometimes explaining complicated stuff to highly placed managers requires inordinate amount of time. Especially when their Kantian "wells of experience" were not there. Without the experience on part of the listener, there is no understanding. In that case these managers will just interpret what you are trying to say.

Now I'm finishing this extract with his last sentence in the book: "I don't believe there are great technical problems in building complex systems. The great obstacles will be in the organization of the workforce, in inter-team and external communication, and in the management methodology; thus the theme of this book."