DAMP V2
 

All companies are dominated by stupidity. What makes the difference is the amount of compensation you get for staying there.
 

  Site about "championism" and "champ" firms on Croatian IT market.          ->Croatian site
  What is championism? | Champion's manifest | The Legend of champions | Weekly poll
  Legend of champions
  Prije (Previous)
  DAMP version 2
 
  Two months after Bojan came to Dodoni, rumour spreaded that Dodoni found another customer form DAMP. It was firm called Highlevel computing, well-known and respectable software company owned by Concord insurances, one of the biggest Dembelian corporations. In all that excitement, nobody mentioned first DAMP client and how they were satisfied with the first version of Dodoni's leading application. It went without saying that the first client is so excited with that product that they demanded nothing more - no upgrades or new versions were ever requested. From time to time they sent some minor bug list and that was all that was heard from them. Given these facts, some sceptic like Bartol or Bojan would assume  that project was clinically dead and that client wanted nothing more from Dodoni. Although it proved true in the following months, at that moment nobody was ready to learn from past mistakes. Instead, Zakro, Stinky and other champions were full of optimism and they believed that this time they would make it right, on time and on budget.

Optimistic start

The first proof that DAMP was really sold to another customer was free lunch in the nearby restaurant. Zakro invited all employees by saying: "People, let's go for a lunch. The contract was signed and we are in. Highlevel bought DAMP."

New version of DAMP was divided into two subprojects - desktop and web application. Desktop version was in fact the old DAMP application that had to be tailored to new client's needs. Unlike desktop, which had all functionalities expected from project management software, web application was only intended for entering employee timesheet. In the spirit of past workshop, where it was decided that every developer could become a project manager, Stinky was appointed a new project manager of DAMP version 2. He was also a head developer of desktop application. The rest of the team included Bartol as database developer, Rudi as report designer, Drazen as VB developer and Bojan as web application developer. Maddog as usually succeeded in avoiding teamwork because he was busy working on one big infrastructure project for another Dembelian insurance company.

The only mystery was Zakro. What was his role in DAMP if Stinky became project manager? What would he do? Quality assurance, reviews, testing..? It didn't take much time for Bojan to find out the answer to these questions, although it costed him a lot of nerves.

On one of their secret meetings, Zakro and Stinky estimated that desktop application would need one month to completion, and web application was scheduled to be finished two weeks later, because they weren't sure how good Bojan was in ASP and he was the only web developer they had.

The first question - what are we supposed to do?

The web application subproject was initiated when Zakro said to Bojan: "Well, as you know, we have to implement timesheet on the web. That will be your task. It must have the same functionality as timesheet in desktop application." And that was all Zakro had to say on the given subject. If Zakro was project manager, Bojan would be surely shocked by the way Zakro assigned a task to him because he would expect some plan, more precise directions or even functional specification. He thought to himself: "OK, this was only a brief explanation. I will get more precise answers from Stinky, who as a new project manager probably had some ideas how to design new web application."

When he later asked Stinky for a specification and functionalities of web timesheet and if there was maybe some prototype, Stinky looked at him with obvious surprise and said: "What is that you don't understand? Web timesheet must have the same functionality as timesheet in desktop application. Look at the prototype we sent to Highlevel." That was the first time that Bojan heard there WAS some prototype. There was even some documentation, but it was written by Zakro and Stinky, so he didn't bother to read it because he didn't want to correct spelling errors.

Prototype under the motto "Who cares for other browser besides the latest version of Internet Explorer?"

Prototype that Stinky created by learning Frontpage for several days looked indeed very nice. Maybe it was because the design and the stylesheet was literally copied from MS Project central and MSDN. The pages were organized in tabbed sheets, like on MSDN at that time. The only problem with that design was that it worked only in Internet explorer because tabs were rendered by hiding and showing DIV tags, which didn't work well in Netscape.

The second problem with tabbed sheets was page "weight". If each tab held a table with the data (tasks, projects, timesheets), then all this data was loaded in one piece and not on demand. When all tabs and their tables were loaded, DIV tags with inactive tabs would be hidden and only one would be visible at the time. That was very nice-looking solution but it wasn't suited for slow Internet connections - if tables with data were big, user on a slow connection would have to wait for a long time for a whole page to load, although he probably didn't need all that data.

Tabbed sheets weren't the only "IE dependent" solution that Stinky used. The other, even worse, was related to design of data tables and navigation. Stinky designed tables so they looked pretty much like grids in desktop application. If user passed a mouse pointer over some data row, that row would be hilited and cursor would change shape into hand. If he clicked the row, that meant he selected it and some action would be carried away (see example).

Can you see the hand in Netscape?
row1        
row2        
 

It was very nice-looking but usable only to users of Internet Explorer. Poor Netscape user would have much trouble selecting anything in the table because he would never see the highlight or the hand. Also, he couldn't click the row either. Because there wasn't an alternative to DHTML navigation, the whole application would be totally unusable to users of browsers other than IE.

When Bojan asked Stinky about supporting Netscape, he got the answer: "It doesn't work in Netscape? OK, if you say so. Anyway, even if it doesn't work, I think it wouldn't be a problem to adapt it to that browser." Because Bojan still believed that Stinky was competent, he didn't think of possibility that maybe Stinky didn't know much about the web programming and that he probably had never developed serious web application that supported both browsers. Many months later, when Stinky gladly offered him to reuse VB modules from desktop application in his ASP code, he had no more illusions about the knowledge of head developer. But we haven't come to that point yet.

Let's throw Stinky's prototype and build something usable

When he realized that Stinky's prototype is full of limitations and that it would be really painful experience to develop anything serious around that crap, Bojan designed totally different prototype. He got rid of tabbed sheets and created separate page for each data table. It was pretty much classical design but it worked and pages were much lighter and loaded faster. He also created browser-aware navigation where application detected browser type and rendered appropriate navigation. IE users would still get the same navigation that Stinky designed - highlight and stuff. However, Netscape users would see the text in data table rows as hyperlink.

Difficult birth of functional specification

To prove he was serious about it, he wrote a document where he put screenshots from the prototype and described in detail every functionality of the application. It was in fact a complete functional specification that he called "Feature list". The main drive force behind writing that document was his intention to force Stinky and Zakro to finally think ahead and define the final scope of the application.

The whole story with the specification began when Bojan created his first normal Netscape-friendly prototype. He decided to show it to Stinky for approval. He didn't want to start any serious coding before he was sure what had to be built. Stinky was up to his head in coding desktop application so he didn't pay too much attention to Bojan's prototype. Instead, he gave only some minor cosmetic suggestions and allowed Bojan to proceed with the coding. Then Zakro came to a scene.

Day after Stinky's approval of the prototype, when Bojan thought he had permission to start design and coding of the modules, he saw the pop up window on his screen saying "Aye, Bojan, shall we discuss some things?". The message was from Zakro. It was his typical introduction to torturing poor developers with his mannagerial crap. Bojan approached his desk and immediately saw his prototype on the screen of Zakro's computer. "Why is he looking at my prototype? Stinky is program manager and he approved it, so why does he bother?"

He got the answer very quickly. As if Stinky and their yesterday conversation never existed, Zakro started to review every part of the web prototype, making new propositions, changing functionalities and design and at the end the whole concept was so different from the original that it seemed that Bojan's work was simply thrown down the drain. In shock, Bojan didn't have time to ask "Damn it, who is project manager here, you or Stinky?" and soon after he found himself rewriting functional specification and the prototype. Then he realized the bitter truth about the DAMP and the Dodoni computing, which was further confirmed to him by Bartol. There was no change in command chain and developers could only pretend they managed projects, but in fact the real and only project manager there was Zakro. On DAMP project, Stinky was only a fictious project manager and the real one was Zakro, as it was before on the first version of DAMP. To make things worse, the two of them weren't even synchronized and each one of them had different vision how application should look like.

Ping pong Zakro Stinky

The best proof that Zakro and Stinky were not synchronized at all in their managerial roles Bojan got the next day. He showed the changed specification and prototype to Stinky because he wanted him to know that Zakro changed many things in the original concept. Stinky was probably in the mood for pretending to be a manager and he did the same thing as Zakro the day before - he started to insist on details and he instructed Bojan to change again many aspects of specification and the prototype. Bojan was about to explode but he thought this was the last change and then he would have the final permission to start developing actual code. Oh boy he was wrong! Only half an hour after the session with Stinky, he was again called by Zakro who, like Stinky never existed, had new visions and changes about the design and functionality of the web application. That was too much even for a calm person like Bojan!

He entered the last changes into the specification and then he added at the end a small paragraph that read: "We agree that the software will be built according to this specification. Project manager and product manager confirm that the specification is complete and that developers can start to implement it. Developer confirms that he understands the specification and that he will implement all features in given time frame." Under that last paragraph he put placeholder for three signatures - one for Zakro as a product manager, one for Stinky as a program manager and one for him as a developer.

After he finished the document, he called for a meeting of DAMP team. When everyone gathered at the table, he showed to them finished functional specification together with placeholders for signatures. He was obviously very upset because he had enough of Zakro and Stinky's incompetence and their constant changing of requirements. "C'mon bastards, sign the damn document so I can proceed with the coding without your constant interruption", Bojan thought when looking at their faces as they browsed his document. 

Zakro's first reaction was as  Bojan expected pure political: "Well, OK, we can sign it, but as you know, requirements change in every project and we cannot predict everything. Why are you so upset about it? Build something and then we'll see if that's it, we've always worked that way.  What is your problem with that?"

"In normal distribution of roles, developer doesn't need to have telepathic powers and try to figure out what has to be done. Instead, project manager is the one who builds the functional specification in several iterations with the client and the development team. When that document is finished, every stakeholder knows what will be built, when it would be finished and how much it would cost. Here this is not the case - it is up to poor developer to deliver functional specification, architecture, design and code. Project manager does nothing.", Bojan replied.

"Maybe you are right, documents have to be written but we don't have time. Krunoslav runs that project but he is up to his nose in programming desktop application, and I am busy with other stuff so nobody has time to write documentation. You are really good in that, I can see", Zakro started to suck up, "starting with the next project we are doing your way, by the book. OK, if we are done with that discussion, let's see what are the other problems in DAMP", finished his reply Zakro.

And so the meeting changed the course, and Zakro and Stinky avoided signing the functional specification. Bojan realized that there is no use in fighting lost battles and that there is no way they could be forced to make things right. They were too dumb and incompetent to change the way they ran projects, now he was sure about that. Except this last revelation, the other consequence of that meeting was that Bojan got the reputation of book worm and the person who annoyes others with unnecessary details like specifications, conventions and quality. He definitely didn't pass as a true champion.

Delivery date

When delivery date came close, it was obvious that desktop application is way behind schedule. It didn't help that Stinky worked overtime and produced his spaghetti garbage at even more speed and it also didn't help that Rudi was forced to replace his theoretical experiments with some actual code. Time was simply running out. Estimation given by Zakro and Stinky was too optimistic even for "code-like-hell" way of work.  

Another typical champion's last minute delivery was on its way (see Champion's manifest for details). It would probably went that way if Zakro 'didn't find the magic formula: "Let's move delivery date for one week and we'll tell them that it is because we want to deliver both the desktop and the web application at the same time." Although the web application was scheduled two weeks after the desktop, Zakro could promise earlier delivery because he knew that Bojan was almost finished with it. Despite the fact that he had to write functional specification and fight with Zakro and Stinky for final scope of the application. And despite the fact that he developed it by the book - using stored procedures, using separate data, business and resource modules and heavily commenting the code, which obviously took more time than if he used infamous copy-paste method. Ah, yes, we mustn't forget that his application supported both browsers. 

After the touch of Zakro's magic wand, everybody was happy, especially Stinky who got extra 7 days to assemble his crap. Off course, he didn't find it necessary to thank Bojan for saving his ass. Anyway, his happiness lasted only until the next delivery date when it was obvious that Stinky needed way more than 7 days to make his crap usable. However, in the last minute he managed to fix something that worked and client got something to install on given date, but as usual, it was buggy and unstable application that once again caused Mr. Dodoni to apologize to the client and promise that those numerous bugs would be fixed in the shortest possible time.
 

  Prije (Previous)