My take on libraries over framework(Spring Boot vs Dropwizard)

I am unable to sleep because of fever so I thought let me write this post. Maybe it is not the best time to write this post but who cares. A couple of weeks back I got into discussion with a customer CTO over libraries over framework. This customer wants us to prefer libraries over framework.This was mainly with regard to Spring Boot vs Dropwizard discussion. 

The best definition I have read on the web about framework and library is that a framework calls your code and your code calls the library API. A framework does much more and has strong opinions. Libraries are focussed, solve one problem, and swappable (not entirely true without proper abstractions).

The customer wanted us to use Dropwizard instead of Spring Boot because of the following reasons:

  • Spring Boot does too much auto-magic. With something like Dropwizard you can have control over how things bind together. You can use manual dependency injection instead of a IoC container doing that magic for you. You can disable auto configuration in Spring Boot. You can also wire beans by hand if you want. But, I agree the default way is to rely on auto-configuration.
  • Spring Boot vulnerability surface area is higher because it is too easy to add starter jars and bring all the transitive dependencies. I think this will be mostly true with any other approach of building software in Java unless 1) you are going down the stackless way(I don’t think Java platform is there yet) 2) you have good governance on what gets in your dependencies. 
  • Spring Boot executable size is much higher. I compared bare bones Spring Boot(spring-boot-starter-web with Tomcat) and Dropwizard(default maven archetype) executable sizes. As it turns out Spring Boot was 17M and Dropwizard was 19M.
  • Spring Boot startup time is higher. This depends a lot on what you are doing at startup. The bare bone spring boot app starts in 1.64 seconds whereas the bare bone Dropwizard app took 1.526 seconds to startup.
  • Spring Boot consumes much more memory. This was true. Spring Boot loaded 7591 classes whereas Dropwizard loaded 6255 classes. Also, heap space consumption of Spring Boot was twice compared to Dropwizard. 
  • Spring Boot apps are difficult to debug. I agree exception stacktraces are too long at times and it takes a minute or two to reach your calling code. But, I personally never had much trouble debugging Spring Boot apps. I mostly rely on good tests and logging to debug stuff.
  • Lastly, they wanted us to follow a general principle – prefer libraries over frameworks.

The funny part is Spring Boot does not call itself a framework and Dropwizard documentation states Dropwizard straddles the line between a library and a framework.

We went with Dropwizard :). I respect their decision and I think their reasons have merit. I myself have seen too many badly architected/built Spring Boot apps so I am open to trying out a new, simpler, and better alternative. 

I have read the Brandon Smith post – Write Libraries, not Frameworks. I also think libraries over frameworks is a good architecture principle that we should strive for. The only problem is when we apply principles blindly without understanding the context. 

I think principles like favouring libraries over frameworks are fundamental. For these principles to work you need to have the right context and provide the right environment. I think it will work for you when:

  • You have a good engineering team that understands the cost of adding libraries. There is no free lunch. It does not work in a typical bottom heavy pyramid team structure where teams are considered feature factories. They will add any library under the roof to deliver features if your mindset is not aligned with the principle.
  • You have good governance. It is enforced by healthy code reviews, automation (aka fitness functions), architecture knowledge sharing sessions, Microservices production readiness reviews, and architects with the skin in the game.
  • You spend effort and resources on developer experience to build tooling that makes it easy to scaffold new Microservices with your opinions and choices baked in. I am not sure how it will be any different from a pure framework approach. You will end up building your own Microservices framework with your library choices. 
  • You train your software engineers to buy into this methodology. They will have to unlearn the existing way and learn the new way to build software.
  • You understand productivity might take a hit till developers understand the new way to build software. Frameworks give you a productivity boost by helping you get started faster and solving common problems for you.
  • You use automated checks to continuously prove that software is not deviating from the principle. You can write a build tool task that fails the build if executable size reaches a threshold. You can write tests that fail the build if people use certain libraries. All of this is possible. You need to invest the time of the right engineers to make this happen.

I don’t know whether this will work in our environment or context. It will depend on if we can walk the talk. I have seen too many times all the good things thrown under the bus when business puts pressure for features.

Looks like medicine(or writing this post) has done its job. I started writing at 2:28am and now at 3:39am my fever is down and I am feeling better. 

Software Development 101: Validate your assumptions

In my last assignment, I was asked to mentor a software development team as part of the Dojo program. I am not a big believer in Training initiatives, but because Dojo program has a different format I decided to take up the assignment. The Dojo program involves working on a real project with the team, helping them embrace good software development practices, solving team’s real problems, and finally delivering a quality software. In this post, I want to talk about a lesson that I had shared with the team — the lesson which I named it as Validate your assumptions. Continue reading “Software Development 101: Validate your assumptions”

What we should not write on company’s blog?

These days organization expects their employees to write blogs/publish articles so that the organization gains more visibility. I believe blogs are a very good way by which you can gain more popularity and visibility in the developer’s community.  But I see lot of blogs published on company’s official blog as  developer’s personal experience or personal learning. These blogs lack the content and value as expected from a company blog. People just write the blog for the heck of writing it.

In my opinion writing such blogs does not increase the organization visibility.There should be a difference between what you should write in your personal blog to what you should write in an organization blog.

The blogs that you should write on a personal blog rather than on company blog are:-

1) Hello World blogs = These type of blogs does not provide any value as you can find such blogs all over the web. They just contain a very basic explanation of the concept or framework with or without a Hello World program. These blogs have one characteristic that the person who wrote this blog will also never read it again.
2) Opinionated blogs = These type of blogs contain your opinion about a topic, concept or an event. Writing opinionated blogs is not bad but
if you are writing your opinion on the company’s blog then it in a way represent your organization opinion also. So, when ever you write an opinionated blog, please match it with your organization values.
3) Blog with links to other blogs/articles= These blogs does not have any content of their own they just point to other links (video or text).

These are some of the types of blogs that should not be written on an official blog. Company’s blog should have good content and quality should matter over number of blogs published. Please post in your comments on what you think.

Reasons for incompetent software developers in India

Reasons for incompetent software developers in India

Most of the times, I have heard that Indian developers don’t have the quality as compared to their counterparts who are working in western countries.  Development teams in western countries often blame their offshore counterparts for slowing them down.  It has been said that Indians are not technically competent; write poor code, they don’t give any suggestions for the problems, etc.

In my opinion, most of these are true. Yes, we are not at par with developers in western countries and we sometimes really suck. Please note that this is just my personal opinion and not all software developers in India are bad. It’s the problem of quantity versus quality. In this blog, I will be putting up some reasons why I feel Indians developers lag behind developers from other countries.

Reasons

  1. Developer by chance not by choice = In India anybody can become a software developer whatever his/her qualification is. I, myself, was a mechanical engineer, but in the college campus was recruited by a Software company so I ended up becoming software developer. Likewise I have so many friends who become software developer by chance. Most of the college students who join any Software company does not know anything about software development or have any knowledge about programming.
  2. College education does not help = I have graduated from one of the good college in India but I can tell you one thing that the quality of education in India is very poor whichever college you get graduated from. In India, importance is given to marks than to practical learning, students just cram the things and get score but practically they know nothing. I recently interview a guy who had close to 6 years of experience, graduated from a good college in Computer Science with a very high percentage, was not able to write a Fibonacci series program.
  3. Developers don’t keep themselves updated = If you ask a developer which last technical book you read or how you keep yourself updated, most of the times you will not get any answer. Nobody wants to learn or improve themselves. Whenever I get a chance to speak to developers I ask which last technical book they have read 99% of the time answer is either none or Head First SCJP book.
  4. Everybody wants to become a manager = In India you can become team leader at 5 years of work experience. Once you become team leader, your next goal is to become manager and for becoming manager you need to be good at giving your work to others, doing dirty politics, and most important doing nothing. So, you can see, we do not know anything about programming when we enter the software development world and at an experience of 5 years most of the developers start thinking about becoming manager. Last week I was giving Java 8 training to a set of developers with average experience of less than 4 years and I asked a question how many of you think you will be coding 5 years down the line. No one raised their hand. I was shocked to see this.
  5. No contribution to open-source community = I don’t know any of my friends or friends of friends including me who has contributed to open-source community.  We can only use the open-source project and if we find any bug in the project we will never fix it but blame the developers who wrote the code.

There can be more reasons but at this point of time I can think of these 5 only.  I am trying to make myself a better developer by reading, writing, listening. Tell me what you guys think?

Anonymous Blogger

Anonymous Blogger

Today, I was thinking why I and many other bloggers write as anonymous blogger without disclosing their correct identity.   I am writing down some reasons which lead me to write in an anonymous manner:-

  1. Fear of not looking stupid: – I feel this is the number one reason why people hide their identity.  This can be related to a blog which does not make sense or poor code examples.
  2. Writing on the topics which you can’t write otherwise: – There are topics on which you don’t want to write with your correct identity like your workplace environment, your manager  J , interview questions and many others. By hiding your identity, you can very easily do this.

Does Java Puzzlers make Good Interview Questions?

Intent of my Blog

Recently i wrote an blog entry on one of the java puzzlers that was asked to me in an interview.I received some of the comments which said this is unfair to ask java puzzlers in an interview.So i thought of writing an blog which discusses whether java puzzlers make good interview questions or not.

Does Java Puzzlers make Good Interview Questions?

I think before answering this question that should we ask java puzzlers in an interview or not we need to define some guidelines about what makes a good interview question. And if java puzzlers fit within those guidelines then we can ask the them in an interview.I am giving my personal point of view please add in your comments if you think something different.

Guideline for a Good Technical Interview Question

  1. Question should be How not what = Should be Practical which means that Interviewer should not ask the definition of some term or concept the interview question should be such that it discusses  practical application of concept.Asking how has the advantage that interviewer gets the correct feedback about interviewee that interviewee actually understand the concept.
  2. Question should be on simpler concepts = Asking a difficult question doesn’t make an interview question good.In my personal opinion interview question should be about the concepts which a developer normally use. You can vary the difficulty level of question depending upon position you are hiring but the concept should be simple.For example you can ask questions on overriding which can be simple or difficult but the concept of overriding is such that every java developer should know.
  3. Question can be Extended =  A good interview question should be such that you can build your interview on that question which means that if you ask a question on overriding you can start with the easier question and then build your interview by asking questions that increases in difficulty.
  4. Question should not be specific to API = The question that i mentioned in my post was good but it was specific to the HashSet remove method arguments. Let me explain, when you create an hashset  like HashSet<Short> s = new HashSet<Short>() you might expect that when you are doing s.remove(i-1) should remove only short objects but when you take a look at the remove method it takes Object .This is something specific to api which  most of the developers might not know. So asking such a question becomes useless.
  5. Question should provide a learning point = A good interview question should provide a value add to the interviewee. It might be possible that interviewee knows everything which is great and you can hire him/her. But even if he/she doesn’t know the answer they can at least  learn a good technical point.

Does java puzzlers fit these guidelines?

In my view java puzzler fit some of the guidelines:-

  1. All Java Puzzler are about How not What so java puzzlers can provide interviewer the practical understanding of the interviewee.
  2. Java Puzzlers are about simpler concepts but the Puzzlers are not simple because they discuss the trap or corner cases of the API. You can use these concepts for interviews but the questions are very specific to api and most of the times should not be asked in interview.
  3. Java Puzzlers can be extended but again because they are not easy most of the times you will not get the correct answer.
  4. Java Puzzlers are specific to API and they require very good understanding of java api.
  5. Java Puzzlers definitely provide a learning value to interviewee because these questions touches the corner cases  of the api which normally developers doesn’t know.

Conclusion

In my view you can ask some of the java puzzlers in an interview as java puzzlers definetly provide a value. Sometimes you should only take a concept and build you question on that and sometime take the whole question. If you think the java puzzler you are asking is difficult and a normal developer who hasn’t read java puzzlers book can’t answer please dont make that question a decider question means your decision to hire a person should not be based only on  java puzzler. Java Puzzlers are definetly very good questions and you should use them wisely in interview.

These are some of my view points. Please share your also.

Does Google Search limits the developer ability to solve problems?

Intent of my blog

I am trying to express my views on the problem which i think google search pose to developers in terms of limiting the ability of software developer to solve problems.May be my point of view is totally irrelevant to many of you but i think getting every answer at the click of just one google search button leads to under-utilized brain.

Approach

In my personal day to day work whenever i am struck with some problem and i think i just can’t think more i just do a google search and try to find the solution to my problem. If the solution which i get by viewing the first few links(which we all normally do 🙂 ) on google search page are relevant to my problem i will integrate(after understanding the solution) that piece of solution in my code and move to the next step/task.

Problem with this Approach

  1. Easy way to get solution :- Once you know that you can find every solution to your problem by googling it becomes a habit and most of the time without giving proper thought or applying your mind you just do google search.
  2. Brain not optimally used:- Because more than often we are relying on search results to give us the solution to our problems we tend to let search engine become our brain and leaving the brain we have do nothing.
  3. Lazy Developers :- This also leads to developers becoming lazy in solving there problems themselves.
  4. Solution doesn’t work as expected:- Because you are not giving your 100% in finding the solution to your problem leads to the another problem that you have not fully understood your problem  and the solution you found by googling was just a partial or incomplete or even wrong solution.
  5. Time Waste :- It happens that you try to put time on solution which are not the actual solution to the problem leading you to tweaking the piece of code to work the way you want and finally if it doesn’t work you just delete the whole piece of code and start thinking in a better way.

Above mentioned are few of my concerns that i can think right now but i think there will be many.

Please share your thoughts also even if you think what i am saying is totally rubbish 🙂