last modified: 12-mar-2017 (11:24)
Recently, I was asked to handle a big enterprise app which was left orphan for few weeks. With enough curiosity, I started reviewing the code; it was all over with in few hours. Here is why (the code is written by developers how have degrees in CS and have minimum 1-4 years of particle experience)
Views, models, database calls, network calls all lie at the same place. There is no concept of separation of concerns.
There is a lot of (I mean A LOT OF) repetition in the code.
Public, static fields are used through out the app for saving states. e.g. one class speaks to the other class by modify a
static field in another class.
As state is being saved in
static fields, the behaviour of app is highly unpredictable.
Some time functions are named like
this_is_what and sometime
Views are wrapped in other views for no reason and developers have repeated this for every layout in app.
Everything is wrapped in
try/catch block for no reason.
I can see a lot of useless code commented but not removed from the app. Perhaps it is more than working code.
There is no encapsulation whatsoever. Everything is public and objects talk to each other by directly accessing public fields.
Android components are used carelessly. e.g. no use of standard toolbar or
ViewHolder pattern in list view and a lot of other things.
There are functions which contain only
setContentView(R.layout.layout_file); line of code and nothing else.
Checks like following are common and used intensively throughout the app.
Even VCS is not used properly. Code is distributed via USB.
There are logs throughout the app without any check of dev or production.
Being an enterprise project I was expecting enterprise quality and why should I not?
I am like other thousands of programmers who code responsibly and spaghetti code is a nightmare for them.
I was in grief, sad and disappointed.
I have been thinking about it for days and wanted to figure out why someone would write such a code. Is this the developer who is responsible or management? These questions bother me whenever I need to patch that code. I have found a few reasons and now I am going to write about them. Before moving on, I want to share that these opinions are my own and may not be perfect or accurate at all. Anyone can disagree with them. Anything I write about software developers includes me too.
Our selection process for software developers is really outdated and limited. Anyone who have memorized a few concepts is able to pass through it. In software industry we don’t need people who are limited to theory. We need developers who apply whatever they have learnt in an effective manner.
Look at the points I have mentioned in the beginning. You don’t need be Linus Torvalds to care about them, these are just normal practices that every developer should care about.
We have to select on the basis of how someone have applied concepts, not on how much they know or for how long they have been in the industry.
Luckily, few days back, I got a chance to interview some experienced developers (4-5 years). All of them have written numerous skills and tools on their resumes. While interviewing, I asked them about those libraries or tools and believe me or not, all of them were unable to give satisfactory answers. Even the most basic questions about programming were not answered.
One of the developers had written
git in his skills and I asked him to rate it out of 10. He replied 10/10.
There is nothing special in
git. I know it all. Push for pushing code, pull for pulling code. Replied a 5 years experienced developer.
We learn to write it on resume and that’s it. We learn it only to answer an interviewer, without any interest in what we are learning.
We are good developers with poor mindset.
Personally, I believe if you know one language and know it well. It’s enough for your life (you can make a lot of money).
It is deeply related to
CV driven culture. Most of the time, developers start their career with reading tutorials and they stick to
it for the rest of life. They learn one thing, know a little about it and apply them everywhere without knowing any concequences.
They do not want to go deep and learn it well. This attitude can work well for small projects but for large scale projects it does not.
They use ignorant use of concepts or don’t use concepts at all, resulting in a product that can never be stable until written from the scratch
With little knowledge, developers inherit unwanted complexities in the project from which they are unaware.
Perhaps it is the most important factor. For most of the developers, it is just their job and they have no interest or curiosity.
A developer without passion is not worth hiring.
This job based thinking restricts the developers from growing. They become habitual to quick fixes and life hacks.
I have been fixing issues which shouldn’t be there at all. Very common scenarios are not working properly. With little observation, I have found that code was written in panic.
If you ask a developer to fix an issue in 10 minutes and expect that he does handle it really well. You are wrong. Developer will do everything quickly without thinking about it, ultimately he/she will miss some scenarios that you will have to fix later by giving him/her more time.
A technical manager can understand it but for a non-technical manager these things do not make any sense, all he/she knows is do this thing in this time.
Keeping developers under pressure and in panic does not yield good results in long run. For short time, you will find yourself doing things quickly but in long run you will be wasting more time to fix the crap you have forced the developer to write in short time.