Champ project management
Champ programming

DAMP fact sheet

DAMP was a leading application of Dodoni computing, a race horse in which Erich invested the most of his money and the majority of his hopes. It had to be a "light" version of MS Project, designed particularly for specific needs of Dembelian clients. On many occasions Erich used to say that most of his prospective customers find MS Project too complex and in the same time not enough suited for their specific needs. In fact, they needed a much simpler application that would in the same time cover all their specific requirements.

The first version of DAMP was developed for NeilHorce, big Dembelian bank. When Bojan came to Dodoni, the first version has been already delivered to client. In the best champion tradition, the first version was unstable, unfinished bug-prone application that soon required numerous bug fixes. In the same time, due to a brilliant champion requirement analysis, client bombarded the development team with equal amount of change requests. Bojan's new colleagues explained that DAMP was the reason that Dodoni started to grew into a real development firm and hired new people. Before DAMP, Dodoni computing consisted only of Zakro, Patrik and Maddog who developed small one-man project applications. DAMP was the first serious project that could possibly involve the whole development team and possibly make Dodoni a success story and launch that firm into Top500 Dembelian companies.

When expectations don't match reality

Unfortunately for Erich, big expectations and huge doses of optimism were not enough for the project to succeed. No matter how much he fooled himself and invested more and more money into that monster, DAMP was still a failure that stood no chance to become successful and profitable project. The main reasons are sublimated in next paragraphs.

Champ project management

The first reason DAMP didn't become a successful project is quite obvious - project manager was Zakro. Although there are people who can turn into a gold everything they get grip on, Zakro was definitely NOT one of them. During the development of DAMP, all his project management "qualities" were clearly exposed:

• Poor requirements analysis according to principle "Read client's mind and never ask questions"
  If at the end you get a bunch of functionality that should be thrown away and entire parts of application rewritten, never mind because there are stupid programmers who will work overtime to compensate for your bad decisions. In most cases Zakro got the requirements document directly from client and since he didn't know the word of Dembelian language he had it translated and then he tried to understand it. The translation was mostly done by Astrid, outsourced translator and sometimes by Erich. In either case much of the original meaning was lost by translation because Astrid didn't understand technical stuff and also didn't have a clue about the business problems of the client. When Erich did her job results were also disastrous, which spoke enough about his knowledge of business and development issues. So, when you add Zakro's ignorance to already unusable documentation and his refusal to ask additional questions, you can easily predict the result of his work and what chances his developers had to deliver the application that could satisfy all client's needs.
  Off course, there were cases where client was extremely fluent in articulating his wishes and he knew to the tiniest details what he wanted and how he expected the application to look like. In such cases Zakro didn't have so much chance to screw it up and if project was assigned to normal developer like Bojan or Bartol, chances were great that client would be even a little satisfied with the outcome. Unfortunately, most of the clients didn't belong to that group because they didn't really know at the beginning what they really wanted. Instead of bombarding them with additional questions and clearing up the requirements, Zakro and Stinky tried to read between the lines and designed the solution they thought it reflected client's wishes. In most cases the end result was that application was good-looking, sexy, full of nice icons and toolbars but completely missed its purpose. The first response of many clients, when faced with the first version of the long desired application, was: "That's not what we asked for!"
• Total absence of planning and design.
  Zakro didn't bother with project planning activities like writing functional specification, verification of the specification by the client, writing project plan with detailed list of activities, scheduling, resource allocation, writing architecture document etc. His project management process consisted of calling his head developer (usually Stinky) into meeting room and discussing what was in client's mind and how application should look like. When they reached some agreement and thought they understood everything, he let developers begin coding and all he had to do was to wait for the first forms to appear so he could make his observations and demand changes. God forbid that he maybe produced some document or application prototype. He considered such things as waste of time and expected that after his directions next step should be nothing but coding. Or better, hyper production of ugly, dirty, Visual Basic spaghetti code.
  It wouldn't be fair to omit the fact that in some projects there were functional specifications, prototypes and architecture documents. But don't worry, none of them was produced by Zakro. He knew how to delegate his responsibilities to other people.
• Unrealistic scheduling.
  The worst consequence of closed meetings between Zakro and Stinky was that they came up with the final estimate and delivery date for which they didn't consult other developers. The same delivery date was also immediately communicated to Erich who would forward it to client so it was impossible to prolong it later. It wouldn't be a problem if the estimate was done correctly instead of being overly optimistic and having only one purpose of pleasing Erich and the client. Delivery date derived from such an estimate was off course impossible but they knew they would code until the last minute and the application would be full of bugs like many times before. Testing would be done by client anyway, so they could have easily omitted it from the schedule. They also didn't count time for planning, design, debugging ("We develop bug-free programs", "We'll debug after client gets it"), testing, code review, quality control, making installation disks etc. 
  To make things even worse, when it came to dividing work among developers, Zakro would use famous method "Give me more Chinese and I'll finish the Great wall sooner" (see story of Erich) and calculate: "We have 100 person-days, three developers, that means we are done in 33 days!" From this absurd calculation they would derive deadline date that would be, as you can expect, totally unrealistic.
  When speaking of the first version of DAMP that has been delivered before Bojan came to Dodoni, Zakro used to say that right from the start it had totally unrealistic delivery date but he blamed Erich for that. He said that Erich set fixed date and demanded that application should be finished by that day. He used that story as an excuse for coding horror that could be found all over DAMP source code and he also claimed that it was a main reason that DAMP had no documentation at all. "We got a deadline for which we knew it was impossible but we did our best to prove we could make it and at the end we succeeded", Zakro would say full of pride. "Yes, you succeeded in creating a monster for which there is no other cure but to destroy it completely and create it fresh from the start", Bojan thought when listening to Zakro's stories.
• Lack of any progress tracking and code review.
  Any outsider who would find himself in Dodoni seven days before important deadline would have no idea that something so important is on the horizon. The atmosphere would be relaxing and calm - some champions would write code, others would surf the Internet, Stinky would send messages to his friends over ICQ, Maddog would spend all day downloading mp3s and porn, Zakro would pretend to write documents and they would all finish their "work" exactly at four o'clock and go home. Like everything was under control and they had plenty of time.
  In most of the cases the reality was quite opposite from their behaviour - project was few weeks late but neither Zakro nor Stinky had courage to face the truth. Even if they realized that they were behind the schedule, they believed that in last few days they would miraculously make up for the lost time and finish all code until deadline. The typical progress control in Dodoni looked like this -  Zakro would summon all developers in the meeting room and then asked each one of them how much work was done and how much they still needed to finish the task. The standard answer was: "90% of my code is finished, there is only some minor stuff to be done and that's all". Zakro wouldn't check the validity of the answer because, although he was incompetent, he knew that when developer said "90% is finished" it really meant "only 50% or less is finished". So he fooled himself and decided to believe in those claims. When everybody spitted out their projections, the meeting was concluded and all attendees happily returned to their work full of new optimism and faith in the project and great leadership. 
  Their optimism lasted until the last day before deadline when they realized to their horror that code was far from being finished, it was full of bugs, unstable and there was no even a theoretical possibility to deliver fully functional version to client in given time frame. Their reaction was typical - panic spreaded all over the office, developers would enter solo-development mode and everybody would try to make his part work without caring for the application as a whole, the deadly code-debug-test spiral would start to spin faster and faster...The craziness would end when they assembled something that wouldn't crash too often and then Zakro would make an installation program, test it once on test machine (not longer than half an hour) and send it by e-mail to Dembelia.
  The described scenario usually happened on Friday afternoon because Zakro knew that it was the best time for delivery since Dembelian clients already went home and nobody cared if champions were late with delivery hour or two. After he sent the package to client it was all over and champions went home for a weekend happy because once again they "succeeded". However, their happiness lasted only until Monday morning when Zakro started to receive angry calls from Erich because client reported that application didn't work or it was full of bugs. Soon the bug list would arrive by e-mail. Zakro's response was typical - he started to assure Erich that it was not such a big deal, that client was exaggerating and that most of the bugs were of cosmetic nature because they focused on business critical functionality. "Most of the things were done, we made it", he would repeat to Erich so everybody could hear him. Bojan and Bartol were puzzled by the fact that at the end he always managed to calm Erich and to assure him that everything was under control and there was no reason for panic. After that life was back to normal, champions would start to work on the bug list at their own pace ("Why four developers need whole week to correct 20 bugs?" - quote from Erich) and the whole process would start all over again. Only difference was that Erich and his firm lost another big piece of respect in client's eyes or in worst case, the whole account.
  • Not learning on past mistakes and lack of post-mortem project analysis
  Typical for Zakro and his right hand Stinky was that they've never learned on their mistakes. Why? Because for them their mistakes never existed - they were simply perfect. Person who wants to improve would need no more than one lousy estimate to decide not to repeat the same mistake again and that next time he should devote more time to planning and project progress tracking in order to deliver on given date. However, Stinky and Zakro repeated the same mistakes over and over again. The main reason was they weren't competent enough to work in any other way and possibly improve their working procedures or quality. Unfortunately, they had power and authority to make their way the only way how to do things in Dodoni computing. It was grotesque to look at them smiling and congratulate themselves when they finished a project. Instead of being ashamed for creating shitty code full of bugs and sending it to client and in the same time forcing people to hit impossible deadlines by working under stress and sometimes overtime and on weekends, they thought they made a heroic effort and that they were geniuses. They would even call the whole team for a drink and there they would again praise themselves and glorify their achievements. They would do the same thing on post-project meetings. Such occasions were used only to pump unrealistic optimism, not to analyse mistakes and try to learn from them. If somebody dared to mention that maybe something went wrong and that everything was not so great and groovy, they would accuse that person of being pessimistic and start to undermine his authority and knowledge by pointing to mistakes he made. The message was clear: "Shut up and don't spoil our fantasy or we will destroy you. If you keep insisting, we will assure Erich that you are the only responsible for all the bad things that happened in the project".
  At the beginning the scapegoat was usually Bartol, but Bojan also found himself in that role.

Champ programming

The second reason why DAMP was a failure was that most of its developers lacked knowledge and experience in building professional business aplications. To make things worse, they weren't aware of that fact.

• Monolithic architecture
  The first version was created by Patrik, Maddog and Drazen, temporary worker. The project manager was off course Zakro. Bojan tried but never found out which one of them was the most responsible for the cardinal sin of the DAMP, the monolithic architecture where majority of the code was written directly inside VB forms, or more precisely, inside event handlers. There were few modules and some classes but 90% of the code has been put inside forms, thus making strong coupling between user interface and business and data tier. Patrik and Drazen weren't so incompetent like Maddog and Bojan got the impression that they were capable of making much better architecture but it was a mystery why they chose to undermine their reputation and create such crap. Maybe Zakro insisted on such simple and dirty architecture because it was the only thing he understood? Maybe he forced others to make quick and dirty solutions because of the schedule pressure? These and the other questions that bothered Bojan were left unanswered because nobody wanted to talk about the first days of DAMP. The people who created the first version reminded Bojan of group of soldiers who committed war crimes and were ashamed of that and didn't want to talk about it.
   
• Random database access
  Monolithic architecture wasn't the only DAMP's sin. The second and even worse was related to the design of the database and the way the application communicated with it. When Bartol first looked at a DAMP SQL database, he asked a simple question: "Where are the triggers and stored procedures?" The answer he got was: "Trig.. what?" It was obvious that most of the DAMP developers learned to program using Clipper and Access and they never bothered to learn what the SQL server was and what were the differences between real database server and the desktop databases they were used to.
  Let's name some of the biggest mistakes in this area:
   
  • VB code was plagued with hard-coded SQL queries. Most of them were coded directly into event procedures of the UI forms. There was no data tier or even separate data access module.
  • On startup, DAMP opened database connection and cached it in global variable for the whole life of the application. If connection crashed or server went down, application crashed too because there was no error handling for such a situation and code optimistically assumed that database would be up and running forever.
  • When opening ADO recordset, application used server-side cursor of type Keyset because Janus GridEx control could have been bound only to that type of recordset. Nobody cared to think about the other solutions because, as Maddog would say, it was faster that way. In the spirit of "code like hell" principle that dominated Dodoni, things like disconnected recordset or unbound grid were treated like blasphemy.
  • Recordset parameters were used inconsistently, without thinking of possible consequences. It was clear that each developer used his combination of cursor type, lock type and other parameters. Nobody ever cared to correct that and make unique rules how to define recordsets.
    In time Bartol made some changes to the database and introduced triggers and stored procedures, but he never managed to persuade all his champion co-workers to actually use them. He didn't have problems with Bojan because he didn't even think to use ad hoc queries in his code, but Maddog and Stinky were different story. Because of their laziness and lack of programming discipline, DAMP remained strange mixture of different data access approaches for a long period of time.
     
• Consisteny and code convention - forbidden words.
  DAMP didn't have any code convention in written form so every developer had complete freedom in his programming style. To be honest, there was one convention that most of the DAMP authors followed passionately. It can be best described as "code quick, dirty, use copy-paste method whenever possible and never, I mean never comment your code!".
  Also, there were never discussions or design reviews how to implement some functionality. Instead, every developer could use any solution he liked at that moment. That led to tremendous inconsistency in the whole application. To make things worse, inconsisteny didn't exist just in code but also in the user interface. Some forms had buttons on the left, some on the right, some had record navigation buttons, some hadn't , some of them were modal, others modeless and so on and so on. The only person that pointed out to that inconsisteny was Bartol but every time he did that, he was harrased by Zakro and Stinky who didn't see any problem in DAMP user interface and code.
  Like user interface, DAMP code was swamped by various and totally different design and architectural solutions. Some solutions were so ill, troublesome and error prone that it was obvious that their author learned to program when created them. For instance, DAMP had custom ocx search control, which was so unusable and poorly written that it was clear to everybody that Stinky at the moment wanted to learn how to write OCX controls so he gave it a shot. Also, DAMP had custom dll written as ActiveX control that was used to impose security on menus and toolbars. Again, it was plain obvious that author thought: "OK, let's see what else we have in Visual Basic. Active X, what's that? Let's try it!".
  As of optimization, there was probably no control that some developer didn't try to utilize. So, some forms had normal VB controls, while others had MS Forms 2.0 family of controls. To achieve menus with icons, Stinky introduced Activebar control although it wasn't very stable at the moment. When new DAMP developer opened source project in Visual Basic IDE, the first thing he probably wondered was why the control toolbox on the left spreaded to the bottom of the screen. If he dared to open References window, he would usually be shocked of how much external libraries were used in the application. No wonder that exe file had 8 Megs in size. Sad thing was that some of those libraries and controls weren't used any more, but nobody cared to clean up that mess. It was obvious to everybody (except maybe Zakro and Stinky) that only reasonable cleanup procedure would be to delete whole DAMP code and rewrite it from the scratch.