Mobile First; Desktop Next

I was recently in a conference conducted by PMI. The organizers were tech savvy  and they had strictly instructed that no one should exchange the cards, instead QR code is printed on the delegate ID cards and you MUST only scan the QR code with your smart phone's QR code scanner to exchange the contact details. It was repeatedly announced and it seemed like they were pretty serious about the so called 'green' initiative.

I was talking to a delegate who was sitting next to me, he is from a very popular mid-size IT company and he was explaining me what they were onto, how successfully they created a niche for cloud and mobility. When we were about to exchange cards, I promptly reminded him of the conference diktat that we are not supposed to. I had the QR code scanner on my 'SMART :)' Nokia C6, I scanned his contact details. His company web site URL was part of the contact details, I clicked the URL spontaneously.

It was a disaster because their web site was not mobile friendly. After shock, he gathered himself to say their marketing team must be working on it. He conceded that he never tried their web site in  the mobile and I could sense his level of embarrassment as he was talking passionately about mobility a while before.

In the late 90's people used to say 'you should not start your marketing campaigns until your web site is done'

10 years later we must be reminding ourselves 'we shouldn't be starting our marketing activities until our web site for mobile is done'

It was confirmed by one of my 'sales' friends too. His story was more horrifying and had material damages as well. Their sales team was trying hard to have a crack into the IT of a prestigious MNC and they were struggling to get an appointment with the CIO of the MNC. They were not able to get beyond the board and the personal secretary of the CIO.

His Manager got a lucky break when he caught the CIO when they were waiting for the same flight. The CIO was relaxed, the sales manager was telling him how long they were chasing him and was trying to sell his company. The CIO acknowledged that he received a few of their general campaign mails and a few specific ones too. Obviously he didn't delete those mails, he was in a good mood that he took one of the recent mails in his mobile only to click the company URL link. The site was not designed for mobile and all that he got to see was a scrambled look and feel. The game was over, a lucky break was done in by their lame duck marketing who had more important things than getting a mobile friendly web site.

This is very important point for the ISVs (Independent Software Vendors) too, if they are starting a new venture they are better off by getting the mobile version first before getting done with the desktop peers. One big benefit is- when you focus on mobile, you always get the 'basic minimum' right first

Don't Love Your Code; Bombard it through 'Refactoring'

Refactoring is a simple engineering technique that our illustrious developers used quite successfully for decades and agile frameworks like xP adopted it to make it an unavoidable tool in the kit of agile developers. But of late, I have a doubt running over my mind whether the new entrants to development accord the same importance to refactoring like their seniors did. I wouldn't put the blame immediately on them though some people may be guilty of not doing it despite understanding the value it brings to the product. Poor education could be one  reason for that.

Impact of Software Frameworks

Apart from 'people and cultural' reasons, there may be others as well. Emphasize on higher productivity and lower cost  by the customers and managers resulted in the evolution of 'near turn-key' solution frameworks and software factories. The obvious result was too much production of auto-generated code that comply itself to a pre-determined architecture, foreseeable structure  and familiar design patterns. Example - ASP.NET MVC project templates.

The moment you choose the project template, your IDE creates the entire solution blue print even with minute configuration details and a hell lot of code. This is great in more than one way- like high productivity, low cost, rapid GTM and even a young development team can scale up to a standard. Down side is nobody thinks it's their code, 'It's my code' pride is gone. Developer's role is limited to mere fillers of code snippets (worse, most of the times even that was googled out) inside the method boundaries. Method signatures too designed by the IDE in most cases.

But this shouldn't be an excuse for NOT refactoring. Refactoring by definition means 'making small changes to internals of the code without changing the externals as and when more clarity on requirements becoming available'. And you do refactoring for engineering reasons rather than functional reasons.

That means you don't need to make revolutionary changes to your code or design, but subtle and simple changes that eliminate duplication, improve readability and maintainability, make the code more tidy and handle logics more efficiently. It's a much more effective practice than the peer-to-peer code reviews, because nobody understands your code better than yourself. To refactor, you need to live with your code for sometime at least just like a poet does with her poetries.

One emotional factor that prevents people from refactoring their code is why should I touch a running code and 'I cannot see my working code being changed for some frivolous reasons'. That's where we need to become less emotional and stop loving our code. We should not hesitate to break a long running code, be bold enough to make it better while seeing that it continues to support the same features as before refactoring.

Have the following in mind while attempting to refactor

• Do refactoring only for enhancing engineering aspects and NOT to add any features
• Check after refactoring if the number of lines of code reduces.
• Check after refactoring if the code becomes simpler. While the last 2 ones are not a must, you generally expect it out of refactoring. Of course simple design/code is difficult to achieve
• You MUST have a set of solid unit tests before plunging into refactoring. Unit tests are such an important cog in your engineering plan
• Most obvious, do not attempt refactoring if you are near to a release schedule
• Don’t try this immediately after coding a feature; it should be done over a period as the requirements and code evolve. You will have a better clarity and new ideas by then