Learning from Failures

This is a developer summary on the project developed and managed from scratch. This is my experiements in last 3 years.

The last project was developed (?) and (mis) managed entirely by me and colleague with the same experience as me. In the process I have understood the importance of design, planning, processes, project management, test management and code reusability, etc. I have learned this all from the failures.
The project was started on a note that it will be a small migration from dot net to java, should be complete in 6 months and we are free to use any thing we want to.

Communication:
The problem started with communication. The requirements were not clear, but as old habit die hard, at least for us Indians, we never bother for a more specifications. Rather, we had imagined things as they have come and implemented. Of course, in the end, the product was not so near to what was expected. It was not far from expected either. But it dragged a project a little bit more, just for rework.

Unit tests:
This is best part of our project. More often we don’t have unit test cases (Junit), but in case where the unit test cases were written, didn’t serve the purpose.
I have noted down the problems below:
- Unit test cases were connecting to database. They will fail in other than dev environment; hence we found a solution to have different config files for different env.
- Unit tests were more close to system tests where we test the entire system and not just part of it.
- Discussed Test Driven Development but never ever tried to implement
- We never had time to write unit tests. ;-)

Code Documentation:
While we always has specification and functional stuff defined on project wiki, we never seriously believed in documentation on code. I know that document is not always helpful or necessary, as masters say that clean code is always preferable.
But we had neither. :-D

Coding Style:
All developers has there own style of writing the code. Hence our code was cluttered with two not so different styles, Hungerian and CamelCase. One developer has declared class variable like m_BlaNothing, while other has blaNothing. The formatting specified for code is different for both developers. Even the development environment was not same, I was using BEA Workshop (Bea’s eclipse with weblogic debugging facilities) and other has eclipse. When the third developer joined the team, he started using the latest version of eclipse.

Design:
Now in India, 3 years of coding experience seems good. I don’t consider myself as a bad developer and colleague is also good thinker and developer. We both had just above 3 years of experience when we started working on this project. Soon after I came to know that we have had very limited knowledge about the designing the software. I realized that I can write a complicated piece of code, but can’t design system entirely from scratch. It’s a huge limitation. Designing software comes with experience and practicing and reading lots of design pattern and much more. And at that time, I knew only one design pattern, Singleton. ;-)

Code Reusability:
We knew from start that code should be reused. But we have lacked with the vision of how to achieve this.
I think following we should have done:
- Put generic code at common place.
- Communicate often about the code.
Instead what we have done is,
- Never discussed amongst us as what we are developing and how are we developing
- The developed code, even if it at common place, is not communicated with others.
Now, the problem started occurring while we were refactoring some code after few years. Many times, we had just updated at one place, forgetting others. So usually we had problems on Prod env.

Clean Code:
Every programmer should read once, Clean Code book. We had done all the things, exactly opposite as what is said in that book. And we faced the consequences.

Half baked implementation of frameworks:
Spring, iBatis, Hibernate etc, was used at will. If developer things that JDBC is his comfort zone, then use JDBC otherwise iBatis. Spring was always underutilized as none of our modules used any of the spring features.

Test Case Management:
The automated and manual tests are managed in Quality Center. We have developed a wonderful script using, VAPI-XP script to automate our web services. We have also managed to use selenium to manage web based modules in quality center.
But the main problems with those test cases are, they check for more conditions than required or specified in test case. Hence test case can fail even if the output is what is expected.


I have seen things going wrong, and managed to correct them. I have learned a pretty hard lesson in all this process. But on the bright side, I have come up as a better programmer. I think that’s the best part.