REFACTORING

 What is Refactoring?

A software is built initially to serve a purpose, or address a need. But there is always a need for enhancement, fixing problems, add a new feature, or enhancing/ modify an existing one.

Periodic changes to the code are made by a plethora of developers of varied experience and coding styles. Hence, over a period of time, the code becomes increasingly complex, adding to its performance and overall maintainability.

To combat this, it's essential to refactor the code periodically to avoid the above-mentioned problems.

Refactoring ensures the quality of the code by restructuring the code without changing the overall behavior.

When to Refactor?

Ideally, refactoring should be a part of the project plan on a periodic basis. It should also be a part of regular programming.

When you have a task of making some fix/ enhancement to the code base, look at the existing code and analyze its readability. If the developer thinks the code is not readable enough to make a straightforward change, take some time to refactor it first. Many times you would already find some code to re-use which is hidden inside some bigger method. Once you refactor them, the job looks simpler.

Then make the required change. 

 

You would notice that it would be a lot faster and less prone to errors/ bugs. 

After a couple of weeks, return to the method and see if it is still readable or needs refactoring again. Chances are, you will find scope for improvement. 

If you visit the same code again after a few weeks, there will still be scope for improvement. 

It's just how the coding works.

Benefits of Refactoring:

1. Improves Understanding and Readability

Translating someones else can be time-consuming and overwhelming. Periodic refactoring improves the design of the software and makes the bigger picture clear. It makes the code easier to understand, and eventually, the software gets cleaned up, for yourself and for other developers who would work on it in the future.

2. Improves development time

Sometimes, it takes several hours just to understand and get the gist of the functionality of a code written by someone else. A well-refactored code is easier to understand and cuts down a lot of development time and reduces regression bugs.

It's easier to write unit test cases for a well-refactored code.

3. Maintainability

Refactoring helps in finding bugs and program faster. It keeps the code clean and organized. A well-refactored code is easier to maintain in the long run.

Automated tools for refactoring

Most IDEs like eclipse/ IntelliJ already have inbuilt plugins that automate the refactoring process. However, it is not mandatory to use them. It is perfectly possible and okay to refactor manually. Just make smaller changes and test frequently to avoid errors. Unit test cases can come in handy too while refactoring. So consider writing as many unit tests to validate your changes.

Conclusion

I have often noticed teams struggling to write unit test cases just to get a good coverage percentage on various quality tools (Sonar, Jacoco, etc.). More often than not, these are mandated by stakeholders to quantify the quality of the source code. But these numbers can be highly misleading, meant only to showcase to the upper management and make pretty ppts.

Periodic refactoring is actually what will get you there. Making enhancements will take a lot less time and it will improve the code quality over a period of time. So it is important, we allocate time to this as part of your regular programming tasks.

COVID AND FEMINISM

Over the new year, we had some of my husband's (Db) college friends visit us over. So we were 5 couples with 7 kids between us.

While I was done preparing tea, Db came to the kitchen to collect the teacups and help me set up the snacks on the table. 

"Oh Wow! Db is so amazing! He helps you in the kitchen!!!"

"Not as much as I would like, he doesn't cook," I said.

All of them exchanged glances and laughed. "Do you expect him to cook or what???"

Another said, "I would be glad if mine did a fraction of what Db does".

And all of these are educated women. 4 out of 5 of them are either currently working or were professionals at some point in their life. And I am appalled at how easily they believed that I was lucky and Db is being so nice by helping me in the kitchen. 

Now it's the covid lockdown, and we have two sets of jobs, one young toddler, and all household chores without any domestic help. And to my deep chagrin, the household work is very unfairly divided between us at 1:3 ratio. While Db openly accepts that this is an unfair distribution of labor, he also believes that he is a lot better than other men because the bar is already so low for men that doing 25% of household work automatically brings him to the "very nice guy" category.

I call Bullshit!!!

While women are seeking equal opportunities at work, men are still considered "nice" if they get their own cup of tea. And, the saddest part is, women believe so too...then how do we expect men to believe that household work is not just a women's territory. 

At work, many times we come up and volunteer to take tasks because maybe it's a good opportunity to learn something new, to get into limelight, and sometimes because we feel that the rest of the team is already loaded. Why doesn't it apply at home, for domestic chores? Why can't men just come up and say "I wanna help!", the same way you would do at work.

The answer to that is simple.

In my opinion, its nothing to do with gender inequality and everything to do with what you can get away with. 

It also often happens with in-laws, where the mother-in-law would expect the daughter-in-law to take up most of the heavy lifting. Happens at work, where some members of the team always try to push work to the hard-working ones until someone up on the ladder notices and questions him.

If there is something that is accepted or not questioned, it would never change.

And to make matters worse, we as women think so little of ourselves and so highly of our male counterparts. Patriarchy is deeprooted into our bones.

At the risk of having an unpopular view, the most educated and feminist women would go hungry on Karwa Chauth for the long life of our husbands. We celebrate Raksha Bandhan to ask our brothers to protect us or do a Teej to find a perfect husband in the future. All of these and more are done only by women for the benefit of their male counterparts. Have we ever had male equivalents of these beliefs? Aren't these blazing examples of patriarchy in the Indian culture we are so proud of.

I know quite some men who are feminists themselves. Db is also one of them. But believing in feminism as an onlooker and actually practicing it in real life are two different things. It's easier when the domestic work is outsourced to helps, but when it means that you actually have to pick up that broom and get your ass moving...then we are not feeling as feminist, are we now!!! 

Men don't want to change because it clearly works for them and women don't because they accept it as 'That's how it's always been'.

THE WORKING MOTHER

I am a not-so-young mother of a 1 year old who believed that she had it all sorted. My partner and me had stable jobs, stable marriage, financial security, emotionally readiness to have a baby...all checked. However, nothing can truly prepare you for whats coming.

After 6 months of maternity leave, we found ourselves stranded with an infant, while it was time for me to go back to work.

Keeping a little human alive, thriving, fed, dressed and entertained is no mean feat, more so with so much information around you. We use apps to track the development of the child and when something looks off it worries us. From tracking the ounces of milk that the child feeds, his gradual process of solid food intake, weight gain, various milestones to be achieved...Motherhood is constant, demanding and exhausting.

For many career-driven women, like myself, while we know that going back to work after maternity leave is going to be tough, many of us find ourselves overwhelmed, unprepared, and often at a crossroads. We enrolled my son into a daycare when he started his 8th month. While the books and apps have plenty of articles that working mothers have positive impact on a kids life and daycare tends to make kids smarter, there is nothing that can prepare you for the guilt of leaving your child in the care of strangers.

Here are some tips that have kept me going. Keep in mind there is no handbook, or anything called perfect parenting. All said and done, we all make mistakes. This is just a comprehensive list of items that has worked for me so far:

1. It's okay to be a little selfish

It's difficult to keep others around you happy, when you are not happy within.

We chose to enroll our son to a daycare when he was 8 months old. It brought in a lot of judgments not just from people at work and friends, but from within the immediate family as well. It was a tough choice given the limited support we had, physically and morally. But I wanted to go back to work.

I’m very privileged to be able to choose whether to work or not. Some women work because they have to in order to feed their families. Some women can’t work because they can’t afford childcare, or don't get a good family support. But I choose to work because I want to use my abilities, it makes me happy. At the end of the day I love my work.

If I had to quit my work and stay at home, it would have felt like a sacrifice. Initially I might have liked spending time with my son, but soon it would have felt like a compromise. It's okay to be a little selfish, so that you are happy and so that would keep the baby happy too.

2. Don't try to be a superwoman

So far, not much has changed with respect my work. I still come to work on time, do the same amount of work with the same enthusiasm (lots and lots of coffee helps) and ownership. Only I keep hard stops in the evening to pick up my son from his daycare.

Many people have asked me "How do I balance work, home, family and self without having a nervous breakdown?". Raise a kid without physical parental support, and work too. I don't know how to answer that, because I don't. Some days I leave my house dirty overnight, most of the days the laundry basket is overflowing, some days I have no time for breakfast and other days I am too tired to have dinner so I literally pass out with my son in the evenings. I haven't any time for exercise, so I don't touch the weighing scale with a barge pole for now.

It's important to accept that we can't do everything, can’t be everywhere. Prioritizing is the key. Do what needs to be done right away, others can be dealt with later...when the baby finally sleeps, or when you finally get a breather.

3. Ask for help when you need

The way the Indian society is structured today, the onus of the overall well being of the child squarely lies on the woman's shoulder, irrespective of whether the woman is working or not. Don't get me wrong, most men in this generation (my husband included) are plenty supportive. But most of their support comes from mentally and morally supporting the wife and not so much physically. While the woman shoulders most of the household responsibilities, the men are being a "nice guy" when they pitch in. If you ask them why didn't you do something, the answer is usually "Why didn't you just ask me???".

So, ASK.
Most men wouldn't turn you down when you upfront ask them to do something (might need a few reminders too, but keep asking). I usually make a list of TODO items and assign the owner and stick it to the fridge door. As and when I finish a task, I tick them off the list and keep reminding him to finish his share. It takes him longer than me, but eventually he manages to tick all off them. Next week, another list. It usually works.

And, irrespective of if you have a son or a daughter, condition the child to actively participate in the household chores. The next generation of spouses will thank you.

4. There is no reason to feel guilty

A lot easier said than done...I hear you.

The constant feeling of not being a good mother, on missing some milestones of the little one, the feeling that your baby loves the nanny more than you. It's all the part of the guilt that we get because we choose to work.

But when I look at the larger picture, the guilt vanishes. I strongly believe I am setting the right example for my son. Raising a son RIGHT in this generation is more difficult than a daughter. If I make unhappy sacrifices for him today, he would expect the same from the women in his life in the future. Its my job, to teach him to respect the choices that a woman (or anybody) makes. That a woman's career is as important as a man, and either of them could choose to take a break if it comes to that.

5. It's worth it

Sometimes after all this, the baby gets sick, childcare falls through, we run late to daycare pick up many times and we ask ourselves if it’s all worth it.

It is.

Your baby loves you, even if he can’t say it. He does not think that the nanny is his mother, in case you were wondering. There is no right way of parenting. It is not necessary that a stay at home mother is doing a better job than you, there is no statistics, no reason to believe that. You are doing the best of you capability and knowledge and that's good enough.

And finally, you have got this.

THINGS I HAVE LEARNED AS A TECHNICAL LEADER

1. It's always the team

Its not about you anymore. It's important to keep aside your ego, the competitive in you and jealousy. The solutions should be discussed and it's okay if a junior or a competitor proposes a better solution than you. You would need to grow a open mind to embrace the best solution, no matter from whom it comes from.
I learned to start the meetings by stating the problem, and the first line post that would be 'So anybody has a solution in mind?'. If I propose a solution myself, I learned to end the sentence with 'I am open to suggestions and feedback'.
At the same time, it's important to groom your team to be open and forthcoming with their ideas. Providing the best technical solution is not enough, it's important to find the right balance between technology and business. Hire the right people, who can groom if needed, and trust eventually.


2. Technical debt is a bitch

You can run but you cannot hide!
If we ignore the debts for too long, it will come back and bite you. Often the timelines are so tight that the technical debts are ignored and just sitting in the backlog. It's frustrating when the managers and business does not give enough importance to the technical debts and they just remain a number in your release notes, only addressing the blockers, or getting the low hanging fruits to maintain an acceptable scores in the various tools to keep the Quality team happy.
That's where our skills are put to test, convincing the business to address the technical debts. A few every sprint and you will see the difference. Easier said than done, but its worth to keep trying.


3. Find the balance between business and the technology

Instead of the attitude to 'get the story done', it's important to see how the solution will fit the business and raise flags if you think it would not work as per the customer's need, or if you think it breaks or contradicts any existing feature.

With years of grooming as a developer, its easy to get shortsighted and only look at a problem from a technical stand point. We usually concentrate in providing the best solution possible in terms of technology and often ignore the big picture. Also, its extremely lucrative, how we can introduce a new cutting edge technology to solve a given problem, but the business often has no time, no budget, and no risk appetite. Frustrating as it might sound, I have learnt to respect that. From a business standpoint, there has to be a balance between the time put in explore and learn this new technology vs the benefit it would actually bring in to the project/ app.

Put in some personal time for a POC if needed and if we can show the stakeholders that we can get it done, then its a win-a-win.


4. Wear any hat that the team needs

Don't consider the non-technical people as muggles, or look down on any role.
In the last couple of years I have worked as a QA, Developer, Support Engineer, Business Analyst, Architect, OPS, Scrum Master and often filled in for the Product Owners as well. I had this whole stack of hats hanging in my coat hanger and wear anything that the project needed at that point.
While it helps unblock the projects at various points, it also added to my personal profile. It helped me build a lot of relationships beyond just my team, my project, my role and profile. The more people you engage with, increases your visibility among multiple stakeholders. They are also more likely to get you involved earlier or give you relevant, timely feedback. Those relationships are important.

5. Leader is known by his followers

Finally, every time any of my mentees have thanked me, I have said the same thing. A leader is known by his followers. Try to mentor the team, keeping in mind that you need to groom them to be independent and eventually have them mentor others some day. Quoting an example from my own experience: every time a team member approached me with a query, I always took time to explain them the history and relevance of the solution and not just how to solve that particular story/ bug. That way, they stay engaged, understand the whole ecospace of the project (technical and functional) and will start getting the big picture sooner. I learnt that from my first mentor.

SETTING THE RIGHT EXPECTATIONS

This is not my typical technical article, just a little restrospective of an experience at work.

I was working with a new member in the team, to provide him the KT on one of our applications. I asked him to pull our source code from git, and he told me that he has never heard of git before. I showed him a few basic git commands and asked him to to set up the code locally. Once he got stuck after a point, he asked for my help. I asked him where he had checked out the source code and he pointed me to his desktop. I found a highly cluttered and unorganized desktop, and the source code of our project was right in the middle of that mess.

That immediately turned me off.
Soon I realized that he had no prior experience with many of the tools and software that we use largely at work. I got pissed some more.
After a while, I went to my supervisor and asked him who had interviewed this candidate for our project. He told me that he had no idea who interviewed him and he was just assigned to our project to be added anywhere we see fit. I was appalled since he was an obvious misfit and had no basic knowledge of things we use on a daily basis. Is it a fair expectation and good use of my time to start training him on basics, which could have been easily filtered during the interview.

Patience is not my strong suite, but I have to play best with the cards that I have been dealt with. But may a times I keep questioning myself "What am I doing? Is this what I wanted to do?" The answer is yes, this is where I exactly wanted to be when I was a starry eyed kid who wanted to be a computer engineer. I chose this. But then I believed I would be probably changing the world with my work.

Like all people born in the 80s, I grew up seeing my parents working the same job day in and day out till they retired. They treated their jobs as jobs, worked like clock work, it wasn't meant to be satisfying, they didn't wish to change the world. They had secure jobs, smaller needs, secure retirements thanks to pensions, and ran through life on auto pilot. Now that they have retired, they spend time adding to the TRP of random TV serials, gossiping about neighbors and relatives, visiting sacred pilgrims and the worst sending useless forwards on WhatsApp and Facebook.

Agreed that this generation has got into easy jobs, I earn more in a day than what my father earned in a month, I bought a car and a house at an age that my parents couldn't even dream of buying when they were at the same age. But our needs have also consistently increased. We don't have secure jobs, no assurance of a pension in our sunset years, the added temptation of the phone on sale on Amazon or order the over-priced pizza for dinner, and a peer pressure to prove that we are better off than what our friends show off on Facebook and Instagram. While I do want to go on a foreign holiday like my friends on Facebook (even if they probably took a personal loan for it), I still lose my hair over my retirement savings plan.

But that is not a bigger problem for us today. The problem at hand is we crave job satisfaction. Many of us entered the workforce with starry eyes with the hope that we were here to make a difference or change the world, we have realized over the years that the most jobs are just soul suckers. Even if I cant make the world turn around with my work, I at least hoped to make a dent or leave a mark somewhere. If you don't own your own startup by the time you reach forties, you feel like a loser, if you do not look forward to your day at work every morning and rather are dragging your feet to work every day, its depressing. You try to shake things up, change things, inspire others while trying to stay self-motivated, or best keep job-hopping for every couple of years seeking gratification, and eventually give in to "leading lives of quiet desperation".

So now what!!! An early retirement. But retire to what!!!
I wouldn't know what to do with myself if I had no work for a week, what do I do post retirement. Scrolling through social media all day...how long can you do that!!! Watch TV serials all day...I don't think so. Spend time with kids...if they have time for you (if you manage to have one that is). Holidaying...needs money. Spend time gossiping with random people..Argh!!!
And what about the financial security. Without that pension, we are on our own. So we keep working, to be able to buy that fancy phone, or post pictures of our good times at a foreign holiday on Instagram, to add to our retirement savings if God forbid we live to see our 90s.
So it's important that we accept that while jobs are not necessarily meant to suck, they aren't going to provide any life changing experience either. Lower your expectations and you probably will not feel like you are dragging your heels through the day.

With that thought in mind, I will step into office tomorrow and continue my KT as planned. I probably won't be able to get the best of my expectations from the new guy, but I will try to make him the best version of himself.

Beyond CAPTCHA

If you have ever filled an online form, you are bound to have encountered a CAPTCHA.

CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart. I haws been named after the computer scientist Alan Turing.

What is a Turing Test?
Turing test is used by humans to see if a machine can converse like a human. The turing test has evolved to an interesting concept. Today, its a scenario in which a human interrogator uses some sort of interface, often a computer terminal, to communicate with someone else. This some one else could be a another computer program or a human being.If a computer program manages to fool most of the human interrogators into believing that it's a human, the program is said to have the turing test.

The CAPTCHA test is a turing test designed as a short hand for a gateway that allows humans to pass through while keeping machines at the border. The idea of a CAPTCHA is  to build something which is simple for a human being to decipher while difficult for a machine to do so. This is important because it does not do any good if it discourages humans to fill out the said firm.
There are a few things a software can do better than humans, like driving a car or playing a game of chess under normal circumstances, but there are still things that humans can do better, at least that's how things stand today.

A simple CAPTCHA example the case where you have deformed letters and numbers semi-obscured by other shapes. While humans can easily differentiate these characters from the distractions, computer programs have a tough time segregating the signals from the noise. 

Evolutionary speaking, while AI keeps evolving all the time, humans have kind of sowed down in comparison. For ex: Researchers at the AI company Vicarious may have just made CAPTCHAs obsolete, however, by creating a machine-learning algorithm that mimics the human brain. They have created a artificial neural network that the firm claims can solve CAPTCHA puzzles by simulating the human capacity of "common sense". It works on a neural network that can suss out the shape of letters and numbers while while filtering out the distracting noise, by mimicking how a human brain works.
The artificial neural network attacks the problem in layers with each neuron attempting a part of the problem and then combining all solutions to come up with complete solution of the CAPTCHA. Solving CAPTCHAs is not the goal of the research, but it provides insight into how our brains work and how computers can replicate it.

According to security experts, we can expect to see hackers to make use of these technologies in a few months. So CAPTACHAs will become less effective in keeping the bots out.
As AI keeps getting better at  solving the CAPTCHAs, designers are coming up with more and more creative ways and these affect both humans and non-humans.
For example some sites have a small passage followed by a simple question about the content matter to test if the attempt was made by a human.

12-Factor Apps in Layman's terms

Popular platform-as-a-service provider Heroku has published a set of best practices called the Twelve-factor-app for building deployable sowtware-as-a-service apps that are

• Portable
• Continually Deployable and
• Scalable

Here are the twelve principles in a more precise and understandable version:

CODEBASE: One codebase tracked by revision control, many deploys 

Put all your code in a version control system, the best option for me is the git.

You can have multiple branches but never multiple repositories for the same service/ microservice. There can be only one codebase per app, but there can be many deployments. 

DEPENDENCIES: Explicitly declare and isolate dependencies

This has been more important ever since configuration tools like Chef and Puppet have been used extensively used by DevOps to automate the configuration and deployment process.

Consider maven as dependency management tool, manifest will be pom.xml, which fetches dependencies as jar (artifacts) from various repositories.

All your dependencies, third party or otherwise must be declared and completely isolated across environments. Most of the modern programming languages have a built-in support for this. You can declare all libraries in your code, and during the deployment pass the environment variable as a part of the command line that picks up the correct file to deploy

CONFIG: Store config in the environment

Configuration are those part of the application that change based on the environment where the application is deployed on. For example database connection properties, application specific information such as host IP and port etc.

There should be a strict separation between config and code. Code should remain the same irrespective of where the application is being deployed, but configurations can vary.

BACKING SERVICES: Treat backing services as attached resources

Backing services refer to the infrastructure and other services by which the application communicates over the network. Database, Message Brokers, other API-accessible consumer services such as Authorization Service, Twitter, GitHub etc., are loosely coupled with the application and treat them as resource.

The idea is to be able to swap any of these resources with a different provider without having to make any changes to the source code.

BUILD, RELEASE, RUN: Strictly separate Build and Run stages

The twelve-factor-app suggests strict separation of the build, release and run stages.
Build - converting source code into an executable bundle known as the build. (jar, war, ear etc.)
Release - Or Deployment. Getting the build and combining it with a configurations of the specific  environment, assign it a unique release number, and made ready to run.
Run - Execute the package on the specific environment.

The 'build'cycle does most of the heavy lifting and the run stage should be very light weight. Tools that help in achieving a full CI/CD pipeline are Jenkins, Thoughtworks go, and Codeship to name a few.

PROCESSES: Execute the app as one or more stateless processes

Modern applications are deployed on many nodes usually with a load balancer to direct the traffic to enable quick request handling. In such cases, we cant guarantee that consecutive  requests from the same client would go to the same node.  Hence its unwise, to rely on data stored in the previous requests, since it would not be available if the next request is directed to another node.
As a rule, you want each of those instances of running code to be stateless.

There are a number of ways to achieve this:

• Save the state of the process in the database or shared storage.
• Use scalable cache storage like Memcahe or Redis.
• Package assets in executables (e.g. by using webjars at build time)

PORT BINDING: Export services via port binding

This is an extension of  the Backing Service factor.
Make sure  that your application is visible to others via port binding, so that other services can use it like a resource.

CONCURRENCY: Scale out via the process model

This is all about scalability. The idea with more smarter applications is to scale horizontally by deploying more copies of our application on multiple nodes rather than scaling vertically, i.e running a single instance on a much powerful system.

In particular, you’ll be able to do more stuff concurrently, by smoothly adding additional servers, or additional CPU/RAM and taking full advantage of it through the use of more of these small, independent processes.

DISPOSABILITY: Maximize robustness with fast startup and graceful shutdown`

Processes in twelve-factor-apps should start and stop in minimal time.

Fast startup is based on our idea of scalability and also gives way to the usage of microservices as opposed to monolithic applications. If an application takes 30 seconds to start up and handle requests, it defeats the idea of rapid releases.

Graceful shutdown also involves leaving the system in the correct state. All resources should be freed and all unfinished tasks should be returned to queue. Crashes also should be handled. Crashes, if they happen, the app should be start back up cleanly.

DEV/ PROD PARITY: Keep development, staging, and production as similar as possible 

In the recent years, its become pertinent to have short and rapid production cycles. This means that the time window between the development of a change and deployment of the said change is become very small, sometimes a matter of hours. With this window being so small, you do not want to spend time on the deployment process, or carry the risk of something breaking in production.

Hence, its highly recommended to keep the developers environment as similar to the production as possible. This includes using the same third party(or otherwise) services, same configuration management tools, same softwares and libraries.

LOGS: Treat logs as event streams

Logs are highly useful. They can carry variety of information on many levels. They can come extremely handy while trouble shooting the errors in production. Read : Logging the right way

Other than trouble shooting customer issues, you can use error monitoring service like  Airbrake or Papertrail or data mining services like Logstash or Splunk.

ADMIN PROCESSES: Run admin/management tasks as one-off processes

Your app might need some admin jobs at times, for example cleaning up the database for bad data, switching on/off configurations or features, generating reports for analytics or audit purposes.

The twelve factor app suggests that you do these one off tasks from an identical environment in production. Don''t directly access the database, do not access it from a terminal window.

SUMMARY:

The twelve principles mentioned above might not seem novel, you might already be using some already in your engineering cycles. But if you are running a microservice architecture, its important that you take these principles seriously. You might not see the benefit right away, but it will become highly important when you are running multiple services across multiple environments.