Binary Kitchen

When I was promoted to replace my good departing team leader last year, he recommended me to read this awesome book The Cognitive Dynamics of Computer Science: Cost-Effective Large Scale Software Development from the author Szabolcs Michel de Gyurky. He studied philosophy since High School, fought wars for the U.S. Army, designed + built many computer systems for the Jet Propulsion Laboratory and consulted some of the finest U.S. coporations. Mr. de Gyurky is the recipient on the NASA Exceptional Achievement Medal.

The Cognitive Dynamics of Computer Science represents the culmination of more than thirty years of Mr. de Gyurky's hands-on experience in Software Development. He often refers to the great German Philosophers Kant, Hegel and Schopenhauer and recasts their theories of human mind and tought to create a unifying theory of computer science and forms the basic architecture for total autonomy. It addresses all the key areas that software professionals like you and me need to master in order to remain competitive and minimise costs.

The hardcover has more than 260 pages and contains so much wisdom so that I want to share extracts with you in two parts. And these extracts are also for me, so that I can go back to these anytime. I also added links to pictures saying more than thousand words. Enjoy!

• The manager of a project also must be the architect of the system whose developers are being managed by the same person. In other words, he is the manager-architect.
• When you hire people to write the software, make sure that you hire the right ones. They cost far more than hardware. This is the rule number one and also the most underestimated factor to reduce costs.
• Achieving a close understanding of the system in the mind of every member of the design team enables the manager-architect to switch positions laterally and horizontally in the organisation without losing efficiency.
• The essence of Schopenhauer's masterwork - that everything in the world exists but only because I think it exists - is a thesis that the view of the manager-architect is complete only to a very small degree of what reality is. Therefore it's very important to meet the minimum requirements and to be as close as possible to an acceptable reality. To achieve this kind of sufficient reality depends on how complete the requirements are (the client never formulates all of them).
• Regarding dialecticts in the achievement of sufficient reality: For the above reasons, offline design discussions where upper managers or even marketing guys without knowledge trying to influence the system, can have devasting consequences to achieving the sufficient reality. Conclusion: Requirements and design are activities that require the entire team to be present if funding and schedule are important
  1. The manager-architect must be the first to present the design team his first thesis by whatever communication ways (persuading, coercing, cajoling, threating etc.)
  2. Other members will view his thesis with skepticism and repond with antithesis.
  3. The dialog follows until the original thesis and antithesis have evolved and merged into a synthesis which then becomes the new thesis, the sufficient reality.
• Never let documentation editors write the documentation. They look at the format and grammar only, not the contents. It's true, most engineers are poor writers. So for documentation elect only those engineers with writing skills to become technical writers.
• When is a design complete and the work can commence? Only when everyone arrives at a point called sufficient reality through this dialectic process, adding substance to the object with few but good documentation. In other words: At this point, the manager-architect can ask those around the table what they see, and the answers all come back very close to the same reality. Anything beyond that is overdesign and a waste of money.
• The flatter an organisational architecture is, the more efficient and effective it is. Like a building, each floor removes an individual from above and is a delay factor, extending the decision cycle by a factor.
• The traditional hierarchial approach for a project organisation (each department and sub-department has its own manager, also called The Third Reich method) is damned to fail and to become very expensive because of the communication overhaul. There is a data loss each time information climbs one level. Also because each manager has his own subjective impression of the work, thus not having the same experience like other managers on the same level.
• For a flatter, nonhierarchial organisation, segments shouldn't be managed by managers hungry for "collecting bonus miles flying around" (title of manager is associated to wealth) but by team leaders. Each segment has its design problems to solve within the overall architecture. So the manager-architect has always access to all design issues. This methodology is called design hub.
• Design hubs might be stressful for the manager-architect, however it reduces the decision cycle to one-tenth compared to the traditional approach and makes sure everyone within the segment understands the design issues. It's worth for saving costs to let a very skilled and experienced manager-architect to make all final decisions who knows the sufficient reality best.
• The technical staff becomes and extension of the architect's technical mind. The administrative staff become the administrative extension of the manager's mind. Both halves, both arms, are equally important.
• Members of the technical staff must also understand the roles and responsibilities of each other segments so well that they can exchange roles when it's required (i.E. someone is sick). Also technical staff should synchronise their minds to each other since they are the same extension of the architect.
• Dont' staff too fast. The initial team which is the nucleus of the project has to work out the level 1 architecture of the system first, then the project implementation plan (with charts) and at last a document with functional requirements (draft). Only after that, staffing requirements for experienced system design engineers can be written and are of utmost importance to reduce costs. Poorly written and vague job descriptions guarantee great toubles.
• When staffed for the next phase, these experienced engineers will develop the level 2 architecture together with the manager-architect, write the final requirements, interface specifications, various abstract documents and will become senior programmers (technical leads) in the next phase.
• By that way - in manager slang - the feared "burn rate" of fundings is rather slow at the beginning which enables you to build up money reserves for problems that will always occur in any project. And anyways, design teams should be kept small ...
• So, in the next phase, make the segments within the flat hierarchy, elect technical leads and hire additional junior programmers. Make sure that there are no personal conflicts because they can destroy a budget.
• The business manager from the administrative extension, who is also there since the beginning with the initial team and shares the same sufficient reality, is always controlling the costs and even the architect-manager should ask him questions like "Can we afford this?"
• Always remember: The less time is wasted, the sooner a project will be completed, and the less it will cost.
• The lessons learned can only be understood after the completion of the project. And those individuals leaving it before it is completed often have negative characteristics like: Difficulties commiting to serious work, haven't matured to the next level of professional competence or aren't team players.
• If you work with psychoneurotics in your team (i.E. shy nerds and geeks with poor social skills), make sure they understand and follow the rules and don't life in their own shell. Make good use of their skills but don't let them ruin your project.
• Regarding communication, about 30% to 80% of a design presentation are missed and always throws production in trouble 4 to 8 weeks later. So the manager must scan the audience very very closely and fire off questions at the first indication of individuals going of of luck.
• For larger projects you can have technical writers. They write drafts using inputs from the design team meeting notes and interview team leaders who can help completing the applicable section of the detailed design. Because technical writers are very skilled in their language, there will be less ambigutions and fewer mistakes. Once this is completed, make sure, everyone reviews the writings and when finished, the design team has to approve it. This takes far less time (about 60%) than if everyone would be writing their part.
• Clients, the proposal authority or any upper managers, can read those design documents and judge if the mission is understood and enhances the trust between both parties.
• Regarding estimation of cost, a budget is somewhat like a trust. If the manager-architect ever loses sight of the obligation to respect the money of others, then be becomes a charlatan, liar and thief.
• Of course, bad surprises might happen. For that, always add a 20% reserve but not more. And supervise all expenses very carefully. That's what this book is all about: Cost-effective software development!
• When the financial reserves aren't used, return them to the client (= the sponsor). They are rarely returned but reduce tensions between him and the project team.
• It is important for software professionals to be able to look back on every project completed and draw from the lessons learned for their own base of expertise and for the benefit of the next project.
• The detailed cost estimate cannot be accomplished without a completed and signed-off Software Requirements Document (SRD). The SRD is the serious contract between the implementing organization and the sponsor.
• When doing design together, best is to let a projector project the SRD on a screen while the manager-architect presents his conceptual design based on it. Every member of the design team is required to interact freely. Criticisms and objections are given and taken until an acceptable design evolves.
• For example, when a junior programmer finds a bug during implementation can offer the senior programmer to fix it himself. The technical writer (the person taking care of the SRD) can approve and check this actions without wasting time and money with another meeting. This happens often and it's okay. Just make sure those cases are simply reported to the manager-architect in form of notes.
• Never have meetings with programmers when they are very productive. In most cases, it's in the morning, so better have meetings with them in the afternoon.
• When you have good control, stress is kept to a minimum, the development is kept on schedule, and the cost of the software is kept down.
• When the time of the manager-architect is tight, another systems engineer can be installed to monitor the progress of the development.
• If programmers with a hacker-attidude code something else than we have agreed in the design phase solely because he's behind of schedule (his excuse), never allow them to do that. They have to live with the design and can't program anything else without design. The project-manager is in charge, not the individual, so those hackers just have to report this and to live with it. Those with no personal discipline cost lots of money and should be fired.
• Because it's in our human nature to make decisions a priori, it's very very important to write the requirements very carefully, to ensure that everyone understands everything clearly (remember: sufficient reality) and to control the whole project very strictly.

I close this first part with Mr de Gyurky's words from page 121: "Computer science is not an academic discipline easily taught, because it requires extensive apprenticeship in the field, as well as in leadership and management, above and beyond academic instruction."

In part two you can read the remaining extracts. Feel free to share your thoughts below.