Tuesday, December 23, 2014

Developing for developers - Designing and developing APIs

Couple of months backs I got a chance to be part of an initiative in our project, where we have to develop APIs for our server platform. The server platform is evolved with one of the project we are doing for one particular client. Now client want to extend that platform to be usable to their other projects. When we say its server platform, it basically manages servers, helps to provision new servers to scale horizontally, provide some platform data such as where some particular data is located. The data is expected to come in terabytes and it has some data storage mechanism which is multi-tenant. It really feels to me like we are reinventing the cloud and I tried to express here and there. Sometimes, I need to be quite, else who is going to pay me:-) Obviously there are reasons from other end also. There are many legacy code to be carried to this platform and client is having security concerns on hosting in the client. If we use Windows Azure, we might be ending up in limitation. Anyway its really interesting to be part of it especially when it is coming to API design and development.

My experience with API development starts with my first company which sells custom .Net libraries .There I was supporting .Net controls and fixing defects occasionally. At that time nobody told me about the importance of API development. But I realized myself, that API is something very important because we are developing for developers. If we didn't do it right, its very costly to change as all of our developers need to change their code as well. Think about the .Net library. Most of  the classes remains same for years. Now we cannot think about Microsoft renaming the MessageBox.Show() method to MessageBox.Alert(). I believe its same for other languages as well. I was really wondering in my early stages of carrier that, how they are coming up with these framework classes, its inheritance hierarchy, members and the access modifiers of each member. If something went to faulty, its very costly to recover.

In my second company, I got very little chance to work on critical APIs, but there were chances to code for their WPF custom control library. But in third and present company, there were no chance  still last 5 years. All I was doing is to help developers to fix their code which they written only to meet the release. Obviously there were some scope of drawing boxes as design. Most of the developers (including me sometimes because of pressure) were not programming, but gathering code to make a release.

When I got the new opportunity, I thought of doing some great things. I already targeted some  developers who are passionate in programming. But unfortunately, I got a completely different team who were gathering code for delivery as I mentioned above. After 2-3 weeks it came to notice that though they were great delivery guys, they are not much aware of SOLID principles or any other software engineering aspects of programming. It was really fun how I came to notice it. As the server platform components are already available in existing application,we started extracting those components. After extracting the code, we decided to re-factor it to look like a platform code.Class name ,Namespace changes etc... The problem started there.

As of my understanding, if somebody who already practiced SOLID principles, can re-factor any code by analyzing the technical aspects / code flow. But here, the team was struggling to re-factor and the reason they told was they don't know the business of application. The timers were really hard to understand for them. I was really wondering at this statement because I had re-factored big amount of code by understanding the logic by looking at the existing code. I had no clue what is the business requirement of those code or nobody gave me requirement documents. I think this is the case with all the service companies who are delivering from offshore. So arranged training on SOLID principles.

This leads to setting up one more training on API design. Or how to design APIs in a developer friendly and long lasting, backward compatible manner. For me too, it was really a learning experience. Got names for practices which we are already doing and of course obtained the experience of other API developers. Embedded the presentation below. Hope fully I can upload the video too.

References

http://wiki.qt.io/API_Design_Principles

Edits

9Oct2015 - Added references section.

No comments: