Over a million developers have joined DZone.

Buggy Code on Production, Survived

· Java Zone

Discover how powerful static code analysis and ergonomic design make development not only productive but also an enjoyable experience, brought to you in partnership with JetBrains

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.


Learn more about Kotlin, a new programming language designed to solve problems that software developers face every day brought to you in partnership with JetBrains.


Published at DZone with permission of Yusuf Aytaş, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}