For those unaware, I was part of a team that failed to deliver a piece of software on time. This is part of a series, which I started with this post with a little overview of what happened and my take on the entire fiasco.
When I entered the company, I had no real prior development experience. Sure, I had side projects during school here and there, but nothing I would consider to be real serious work. I had never really worked with a revision control software and I had never even touched an IDE before. It was quite a learning experience for me in the first few weeks, that is, learning about the tools and how to use them properly. A few weeks in, I had learned quite a few new things from my lead and ultimately placed all my trust in him. After all, he had over twenty years of experience, why shouldn’t I?
Those were my famous last words for the project, because I shouldn’t have. There were a lot of bad signs, and I should have noticed them earlier. My lead’s beliefs regarding on how to run a team was, dare I say, a little bit off from what I would consider industry practice. We did not have any code reviews because “we had no time.” We didn’t have milestones or deadline for deliveries because it’s an “engineering effort.” We didn’t have a clear requirement specification because a PowerPoint presentation was enough to define the software’s end result.
Looking back, I would consider the leadership to be inadequate and inexperienced. Don’t get me wrong, I did learn a lot from him. I learned what not to do if I ever lead a team.
In many conversations with him, he had explained to me the “three pillars” of software development. Quality, time, and functionality. All three are delicately balanced and intricately connected so that you cannot adjust one without affecting one of the other two. Higher quality means more time, less time means less functionality, so on and so forth. I completely agree with him, though, I would say that we disagree on is the execution of this theory.
He would constantly argue that we should ship software quickly, but we never actually cut down on any requested features. We were pushed to 80 hours / week, our productivity aggressively declined, we did not ship the software. There was too much to do, quality requirements were way too high, and there were too many features. Most of us developers know that pushing hours does not necessarily make software development any faster. We experienced that first hand.
We had atrocious bugs. Some would cause IIS to crash, others would cause the browsers to crash. On top of these, we had hundreds of less serious bugs. The problem of course, was we had no time to fix them. On the last push that I did before the “launch”, in a stretch of 16 hours, I fixed 30 bugs. I’m sure I introduced several more to the system, but gosh, that’s a lot of changes to a system to be launching. Of course, it isn’t as bad as it sounds because we had unit tests right? That’s where we went wrong again.
We had no automated tests. Need I say more?
We started to have so many bugs that it was out of any one person’s control. This avalanche of bugs kept us chasing our own tail. At one point, you would expect someone to say “enough.” Nobody did for another two months!
Now, what did I learn? A lot. Review code, write tests, voice concerns, work less, cut features, ship product, make money. We did none of that.
No tags
