You Got to Believe

We had a number of changes to make to our system recently. Once of the changes was still in a state of flux when we completed gathering the requirements. So it was delayed a bit. All of a sudden we needed to create a design for this change. The design work got sent to me. I was told to spend a day banging out a design. This was a large change. There was no way the design would be complete in a day.

I spent almost a week putting together a design for the change. For the items I knew I would code myself, I skipped over all the detail. I completed around 90% of the design for the rest of the system. Some of the items were put together quickly. But I mapped everything out and provided almost all the details.

Then it came time to code up the changes. This is supposed to be the fun part. I went to town writing the part of the code assigned to me. I spent most of the time testing out my changes. This was a part of the system that requires a lot of complex test data to vet. Another developer worked on most of the other changes. He called me up with some questions about the design. I explained everything to him. He seemed good.

Towards the end of the design, the developer working on the code came to me and said he could not get some of the data to turn out correctly. I recommended he dig into the code and find out why things were going awry. The developer later came back and asked me if he could just hack some code onto the end of the process. Now I am just a peer of this guy. But since he was coming to me for advice, I recommended he trace the code from beginning to end and understanding why the result were going wrong.

Later I get many emails and calls from this developer. He traced the reason for the problems. And he was asking me what to do. This is very disturbing. The guy isn't a newbie from out of school. He is an older developer that has a Ph D in Computer Science. I give him some quick ideas on how things should work and send him off. He comes back to me and tells me things are not working as I had explained. Fine. I took a deep dive and found that things were indeed more complicated than I thought. So I provided some advice on how to proceed.

A week later I get more more questions from this guy on what to do. We are in a crunch. But I still tell the guy how one would figure this out. He proceeds to do so. But he still comes back to me to report his findings and ask me if what he did is correct. I got to figure out how to coach this guy. Perhaps he is afraid of failure. Or perhaps he knows he is going to fail and needs someone to assign blame. I don't know. I need to find out. I can't keep on doing his job and mine. No time for that.

The Requirements

I am taking an advanced JavaScript programming class at the local community college. Last week we had our first quiz. It was really a test in disguise. Who ever heard of a two hour long quiz? There were just four problems. Three out of the four were easy. The fourth one was a kiler.

The instructor told us we could read over the quiz and ask questions in the first 15 minutes of the quiz. I read through all the questions. The hard problem was a use case for a whole program. There were some sentences that made no sense. There were ambiguous requirements in there. There were also some conflicting requirements. So I had a lot of question.

In the end, I determined that the instructor was just checking whether the students were able to discern the loose nature of the quiz question. He answsers to my questions pretty much told me he did not care what assumptions I made. In the end I really liked this quiz question.

My technique to solve the questions was to get a prototype up and running really quickly. The prototype just had a button that added text to a list on the web page. It worked. Then I slowly started adding functionality. I tested my code during each step. That ensured that I could turn in a working product even if I did not finish. In the end, I finished early.

Avoid Duplication

The customer needed some sweeping changes in our system. Happens all the time. However we were busy with all kinds of other changes. So schedules were tight. The project manager said we would put these new changes on hold. That way we could finish our current changes and address the new ones in due time. Worked for me.

Then our project manager went on vacation for a whopping month. The deputy project manager took over. He must not have got the memo. Or he did and ignored it. All of a sudden, we were on the hook for all these new changes. This new manager told me to knock out the design in a day or so. I informed him there was no way that was going to happen. We had costed the effort. Design was a long term effort. But I spent about a week and knocked something out.

There was also a rushed review with the customer. Turns out not all of my design documentation was sent to the customer for review. Never mind that. I was apparently late for coding. Then I started doing some coding. Finally I had to call shennanigans. This was just not how things could work. I escalated up the problems, and got some time to do the design. There was gnashing of teeth, but the schedule got extended to do design.

I ended up with an accelerated coding phase. And then the design walk through with the customer happened right about when I was finishing coding. So much for dependencies and the good old waterfall method. Then guess what? Not all of my documentation got sent to the customer. This was starting to sound like a bad movie. More on this later.