And Vijay Says…

I had an extensive debate recently on why monoliths are not universally such a terrible idea, where a young developer told me “Most of the code you would have written in your time as a developer is now what we call legacy code” .

I don’t blame the young man for thinking “legacy = bad”. I believed it too when I had his role many years ago . And then my thinking evolved over time and I am sure his will too.

I wrote this blog “Nuke that code, lets start over” nearly a decade ago, and I think many of the points discussed in there still hold true . There is a lot of wisdom in the comments section under the blog that I just finished reading again .

The young man’s comment made me think a bit about all the code I have written – from games in BASIC that I have sold to others for 50 rupees on cassettes while in high school to C/C++ , ABAP and java Programs that did more “Enterpisey” stuff for big companies across the world .

“Most” of the code I wrote probably have not lasted very long at all !

Some of the best code I wrote never made it to production – because priorities changed, projects were shelved , acquistion happened and a host of other reasons .

Most of the code I wrote has been refactored – some times by me , but mostly by developers who owned those repos after my tenure . I know of a couple of places where a bit of my code still runs in production – but it’s a tiny fraction of what I have written in total .

Legacy code survives because of many reasons – some good and some bad

1. It does something exceedingly well and it’s hard to make a case to replace II

2. It is way too complex for anyone in the team to rewrite now – usually due to poor knowledge management , not because the code itself is bad . Even with sophisticated tooling – it’s hard to understand logic completely from code, DB schemas and logs .

3. Refactoring is a routine activity in good tech shops . But the truth is that vast majority of large enterprise shops have ignored the importance of refactoring for a long time . They paint themselves to a corner and then need massive modernization projects to get out of the mess and cater to the business needs of today’s and tomorrow’s market . It also shocks me that some shops after finishing the modernization, they still refuse to follow any structured process to refactor along the way !

4. Another common pattern I have seen is that modernization is attempted purely for “tech fashion” – and usually with tragic results . I was quite amused once to watch the code of MRP process be rewritten to a new technology only to realize that even though the results now showed up in a fraction of the time of the old system, it was all wrong and hence useless !

Being honest about the need to rewrite is a good starting point in all modernization projects . There is only limited time, effort and money available and there is never a good reason to waste it by doing a project for the wrong reasons .

“we need to modernize because mainframe is dead” or “we need to move to NoSQL because RDBMS is dead” or “Our code base is a big monolith and we need to be serverless for our future” . It’s very common to hear these kinds of reasons being touted as the reason to start a modernization project . These are not bad reasons by themselves !

These statements are all good starting points to explore what is the real issue – do you take more time to deliver a new feature that business wants , and is that leading to less than optimal business results ? If the answer is yes – is it a tech problem or a process problem primarily that causes it ? Can you quantify the value of changing to a new system and prove that it is greater than the estimated cost ? What happens if the modernization project fails – how much risk can you take ?

Bottom line – you need an honest case for why you want to modernize . This case will then serve as your North Star in your modernization journey . It also will serve as a dose of reality check – which we will all need from time to time . The case itself has a shelf life – so it’s important to revisit periodically to check what changes are needed .

Big Bang vs Incremental changes – how do you decide which is the best way to go ? I will share some thoughts on that in another post . For now , I need to get back to my day job 🙂

As 2019 is heading to its last few weeks, I had a chance to catch up with a lot of friends, mentees and my own mentors and also take some time to reflect how things worked out for me this year . The consultant in me immediately started grouping and classifying the common themes, apply MECE , and map it all to a 2 X 2 . Don’t worry – I somehow resisted the temptation and stopped at just grouping 🙂

I thought three repeated themes were worth sharing here on my blog .

1. You need to tell some managers what they want to hear

So there is this guy who comes from a non tech background and does a good job managing a team of developers to hit milestones ahead of schedule (mostly by overworking them) . He is a flight risk, and the only way to keep him is to promote him to an executive rank . If he flees, his manager probably won’t earn his own promotion any time soon – so there is plenty of motivation to make this happen.

The only trouble is that this promotion needs the blessing of a very senior tech exec . There is no way this non tech dude is going to pass that level of tech scrutiny . That’s when the manager has a flash of brilliance in his thinking . The senior techie is somewhat of a philosopher and his current pet topic is “culture”. He coaches the up and comer to focus heavily of culture when the interview happens – which he masterfully does and gets promoted .

About half the people I caught up with had a similar story where promotions or raises were secured by telling their bosses what they wanted to hear .

2. Diversity seems to be a bit easier than inclusion

While it’s still a long ways to go, a lot of managers have been acting on improving diversity in their teams . There is a lot more awareness and training at all levels . In many cases there are top down directives like “by end of the year there needs to be X% women in your team , Y% URM in your team” etc . In a some of these cases, these are KPIs tied to the manager’s bonus too . All of these are great of course – and I hope it’s not just a one time exercise .

Then comes the question of inclusion . Are these “new” members of the team supported and set up for success ? Are their voices considered with the same importance as when your team was homogenous ? I was a bit surprised that even the people who actively champion the need for diverse teams haven’t done as much thinking on how to make inclusion happen in their day to day work.

That said – I was quite happy to hear that almost everyone I spoke to had done something good about making sure people doing similar roles are paid the same.

3. Being a newly promoted executive continues to be really hard

Before I made Partner , I had attended an exceptional internal training course in IBM called “Cornerstone”. And that’s where it was drilled into me that “what got you here won’t get you there”. Excellent advice which helped me and many others who attended that course . It is also very hard to put it into practice !

Everyone wants to make an immediate impact as an exec . Most have someone else they treat as their role model and want to be like him or her. Nothing wrong with any of it – just that what works for one exec in one context might not translate 1:1 to you in your context . Almost every single story I heard from the newly promoted folks made me say in my inner voice “oh no – I did that too” .

Here is one story I heard from someone who got promoted and took over a new team as its leader in January 2019. All six direct reports were asked to make 1 hr presentation to the new boss . The first one made a less than stellar presentation in the new manager’s opinion and the next day it was announced that this person will have a new role to be announced soon . Long story short – we are in December now and that position is still not filled , and two of the key next-in-line leaders quit because they couldn’t stand the ongoing chaos.

I asked them what were the words of wisdom they got from their leaders after their promotion and it was the usual list of “Have a bias to action”, “Lead with courage”, “Make your voice heard” etc . Those are all invaluable in their own rights – but perhaps we should add “slow down a bit now to speed up later” to the list .

A young engineer I met last week asked me “Sir, you have had an impressive career since the time you left college . Did you always ace every job interview? ”

That question took me back a couple of decades and I realized I only aced one from the first four interviews – which was when TCS hired me from Business School as one of their first SAP consultants.

The three I failed were all painful at the time – but funny enough in hindsight . So I will share those three here – just for some fun 🙂

1. INFOSYS

It must have been 1996 or 97 . Infy was THE place to be – hot young company where all the cool kids got hired . They did not visit our college – but they had an open hiring day where we could apply and go through their evaluation process .

If I remember right – it was a three step process . Step 1 was a multiple choice test on math etc . Step 2 was a problem solving round where they gave a puzzle and you have to solve it and walk the interviewer through your solution . And the third – I am told – would have been an interview with a senior exec and an HR partner .

I had no trouble with the written test and was asked to appear for the problem solving round . The interviewer was a young lady not much older than me. She gave me a printed sheet of paper which explained the question . Funny enough – I had once solved this exact question and in full honesty I told her that I already knew the answer . No problem – she found me another sheet with a different question . And she sat across me , crossed her legs and started reading a copy of CHIP magazine . Well – I couldn’t solve the problem at all and I gave up . She promptly kicked me out of the process and said I can apply in 6 months again .

I never got around to applying again 🙂

2. IBS

When I was in Business School in 1998 , IBS was just getting started at Technopark in Trivandrum . Our Dean , Dr M.N.V Nair , asked me and few others to check it out . A bunch of us took him up on it . I remember a very fancy office and some well dressed people conducting the test .

The written test was on logic and quantitative ability – I aced it . The very pleasant HR lady told me that I only got one question wrong and that I was the highest scorer she had seen till then . So at this point my confidence was sky high and I had no doubts that I am going to kill it in the interview as well .

There were four interviewers in the panel – including the company CEO and the CEO of Technopark . Right off the bat they congratulated me on the high test score and asked me what was my strategy for the test . I said I solved the easy ones first , then the medium complexity ones next and finally attacked the hard problems for which I had conserved time .

That was the end of the interview . One of the panel members cut me short and said “You won’t be a good engineer for us . We are looking for people who tend to attack the hardest problems first” .

Uh oh !

Never tried to get a job there after that . When I reported back to the Dean – he said “everyone makes mistakes”. I didn’t quite understand whether he was referring to me or my interviewers 🙂

3. SAP

While I was working as an ABAP programmer at TCS in Colorado Springs, I interviewed for a programmer role in Washington D.C with SAP in their public sector development team . I did fine in the phone interview and the in-person HR round . Then a Dev manager did a technical interview with me – and asked me to write some code on the white board . We had a great discussion on optimizing performance of the code I wrote on the board .

Pretty soon the interviewer and I were furiously writing and editing code on the board and then at a random point he shook his head and declared “I can’t hire you man . You got the syntax of FOR ALL ENTRIES in ITAB wrong . I cannot look past that . Sorry – you can leave now” .

This was painful ! I knew the syntax since I used that construct quite often in daily work . Somehow I messed it up that day and if it was done on a computer – obviously I would have fixed it in a second . But it was not to be !

Several years later – I did get hired by SAP . And I recently read somewhere that “for all entries” is no longer cool in ABAP once ERP moved to HANA . Oh well 🙂