Skip to content

Buggy Code on Production, Survived

In a life cycle of a project, you come across different situations, you may or you may not overcome these both mentally and physically. Luckily, we have survived through this life cycle with “buggy” code. However, we may not overcome for the next time. Thus, I want to share my experiences over things we have done right and things we have done wrong. I do not want to go in detail but I want to focus on overall picture.  Below, I will share both right and wrong parts.

What we have done right? We used scrum as our agile methodology. Accordingly, we had daily meetings and discussing sessions. In these sessions, we tried to overcome difficult problems and made brain storming. Outcome of those sessions were always testing. As a result, we have written many test(black box test) to verify overall system working correctly. These are the some good things we have done.

What we have done wrong? We did not end the scrum session on time. They always become longer than 5 minute and they rather become design sessions. Moreover, design sessions we had were not that good since whole team did not participate. What is worse, team members did not want to listen. They rather avoided listening and suggested their own solutions. I guess, we all should have respect to the other developers since they can somehow improve application. If you do not believe s/he can improve, s/he should not be on your team.

The worst part of what we have done is testing. We did not write many unit tests and we believed in ourselves so much that we thought we do not need tests. What was the outcome? It was simply disaster, we could not figure out where the bug is. Code become more complex than ever. At the end, we went mad and tried to find solutions day and night. We all got very tired and we did write more buggy code. The more time passed, the more furious we become. At the end, we became code monsters.

Regardless of the bad situation, we luckily achieved to survive. I said luckily because we found the bugs on time; however, we may not be lucky again. Moreover, our managers handled the bad situation perfectly although we missed the deadline one week. They did right things in the right time. Nevertheless, we have lots of spaghetti code which is neither understandable nor maintainable. At the end, I guess I have learned very much from this coding hell. Things I learned are being organized, writing testable code, designing each part and last but not the least being respectful.

To sum up, we may have tight deadlines, we may have difficulty in understanding each other and we may have difficult system to figure out but we should control ourselves and focus on what we are doing. Consequently, lessons are to be learned sometimes by reading and sometimes by experience, the important part is remembering them.

Oh hi there 👋 It’s nice to meet you.

Sign up to receive awesome content in your inbox, every month.

We don’t spam!

3 Comments

  1. Serkan ÖZAL Serkan ÖZAL

    guzel yazi

  2. That’s the point when one solely realise the importance unit/integration testing, when project reaches its deadline, i.e. makes it out dead or alive 🙂 seems like that it turned out good on your end, that’s what I heard at least:), and yeah designs tend to start to resemble with a ravioli dish but ends on to more look like a spaghetti dish. Things get inevitable if you don’t wire tests on top of the ‘living’ code. Mindset should be capable of handling that the project is a living creature as I emphasised, evolves from very beginning to the end, like literally nurturing an infant. If you blink or take your eyes off of him for one second, problems arise and things get messy. yeah sometimes total b.s. so being agile and applying XP could be lifesaver at these times of design/development/testing/whatever. Above all, being a team is what makes a project a success. We humans are not identical but that’s the greatest part IMO. Having the same clone in the team for ppl of 10, would be sooo boring for sure and creativity would be the bottleneck instead of the workforce.

  3. Your next challenge is refactoring then!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.