There are times when things become an uphill task all of a sudden. It happened to me in my last assignment. I was asked to take charge of an existing product. The product has been under development for about 2 years, and now it needed to fix a few things so that the system can scale well.
It started quite well, as the complete things was based on a licensed product from a vendor. The technology had loads of docs explaining things in quite detail. So I played around the technology and it performed well.
Next thing inline was to have a close look at the project, to see what needs to be fixed. Now, when I took the plunge, I had a sinking feeling. The project lacked some basic code hygiene e.g. the build scripts were broken. Then I questioned the team how they are making builds ? The answer was “Ecllipse-> Export as war”. Thus I thought of fixing build as the first thing. But the moment I started fixing them, I realized that the scripts were doing a lot of things which no one completely understood. The script was shipped with the product and most of the time a few of it were used, to generate the UI components. As I started playing around with build I was getting more enlightenment about things wrong in the project.
In the absence of the script the project did not compile completely. There were sources which used classes from the older version of the project, which are not used now. Also the context xmls needed to be corrected for the same things.But after playing around with build for a couple of days I was able to get it working completely. While working on the build I had an initial thought of migrating things to maven but realized soon that it is a quite a task and discarded it. During the same period I was having a chat with the assigned manager. He was pushing for TDD to the team and I was telling him the project does not build. He said ok, lets just start in sometime, I was thinking how can you tell a team what TDD is if the build process is not in place. Anyways, I did not have discussion in that regard for now.
Next thing on my plate was to interact with SOLR via the licensed product. After all the headache of build, this looked like an exciting thing to work upon. As soon as I started I realized it is again an uphill task. The licensed product worked in a particular way while interacting with external services and things must be extended in the similar fashion. Then the next question in my mind was, does anyone know how the product does it ? And the answer was debug fa silence, a few hints came along the way. Now again I started to debug things in-order to look for how the underlying technology does it. A problem in such situations is that you have limited amount of sources at your hand and if you get stuck then wait for a discussion with the vendor. It took me around 3 weeks to completely understand it and then develop a simple interaction with SOLR.
After doing it twice I realized the biggest problem that comes up is the in-experience of the team w.r.t the underlying technology. Also if the team is mostly having in-experience developers e.g having at max exp of around 3 years, then it plays havoc it the development. You would always want to add latest features which the user demands. Try to fit the latest tech stack with the best practices. But you should understand that knowledge and hands-on experience of technology is a must. In the absence of either of the two, you would be able to create a product but the same would not be able stand-up to the mark. It would do things asked for but the moment you want to do extend it to do some other things you will definitely have a headache. Lack of understanding also makes the life of developers very difficult as they are running around for basic issues in the technology used.
Development in any technology open-source or licensed always asks for some basic principles and guidelines. Most importantly it asks for complete understanding of the technology else it becomes quite hard to move around. Check your project if you are missing these things then you are definitively in SOUP.!!
Reference: In-experienced development = Bowl full of Soup from our JCG partner Rahul Sharma at the The road so far… blog blog.
