The conversation that changed the way I looked at writing software programs

When Santa comes to town, we get goodies, when a Wise man visits, we get salvation.
Living in Singapore changed you forever, you will never be the same and will never see things the same way again. I mentioned this to a friend who lived abroad, working for a renowned Airline company in the world.

He paid a visit to my hometown after his probation and we were having dinner together with friends near my college campus. While we were quickly checking through the menu, he started chatting about the future in IT industry and what it would look like. He was very enthusiastic about narrating his experience in the office and how he was pleased by some of the experiences he had in the office.

As we were passing around a plate of roasted Crab, he gladly began explaining what life was like for him in Singapore. He told us about the work, culture, experiences, and opportunities that he was exposed to abroad. As we switched our discussion to technical topics, he started talking about a programmer in his office who write 300+ lines of COBOL code in a day, compile it once, push the binary for execution and go home. The team was using IBM mainframe systems and in those days these systems are being used more selectively and efficiently as each minute of utilization will cost money. My friend was very much amazed to see how someone can write code that compiles successfully in the first attempt and run without any glitch.

At the end of the conversation, when everyone shuffled out for the night and mumbled their goodnight’s, I couldn’t sleep, I kept thinking about this man who can write the code without any bug in the first attempt and able to run the batch program without any tester. Instantly he becomes my role model.

I have seen project teams who find solace in 90/10 rule of project management where the last 10% takes 90% of the time. They always quote this to justify project overrun. The real issue is that developers who are backed up by one or more quality assurance (QA) testers don’t fully test their code and the QA never put effort to fully cover the scenarios. The responsibility is split between them. It’s vague. The developer is busy producing new features, to finish the first 90%, but only at the last 10%, we get the system to the actual users and it doesn’t work.

There is merit in insisting developer-based testing in software projects, ask the developers to produce automated, integrated, code-based tests and measure the code coverage. Only when the developer understands the user scenarios well, he can do the job right. I would like them to cultivate the habit of writing code that works. I am not saying we shouldn’t have testers, but they are not paid for pointing developer mistakes and programming bugs.

Today I am on the verge of completing my 20th year In the IT industry. I have executed many different projects of varying sizes. I always believed in developer-based testing in our projects and the results are amazing, with no obvious bugs, no cost overrun and better customer satisfaction and we never had QA’s in our team.

Winning Customer

Customers are our business assets, no one disagrees with it, but winning a customer is not just about winning their business, it’s about winning their heart. Business is all about faith & trust, we must earn our way to a good relationship with customers. For any successful business there are long term vision, sustainability & profits, if you reverse the order, it’s only counterproductive.

Most of the startup or SME companies are focused heavily on acquiring new customers. It’s not a bad thing to acquire new customers, a startup has to acquire new customers to become a viable business, but as the company grows in size, it becomes imperative that the lifetime value of its customers should be improved, it must be significantly more than their acquisition cost. If you are dealing with too many new customers every year, you are not only draining the company resources to onboard and gain the trust of the customer, it will also impact the company’s brand in the market and employee morale.

To win over a customer, we need to master three essential components. A sound psychologya logical solution, and an effective risk management plan. These are like 3 legs of a stool, you lose one, you will fall. There is no shortcut to this, people want to believe they were smart, they over-promise, provide unviable solutions and do not focus on the business benefits. Even though their smartness brings initial successes, it is short-lived and wouldn’t add any value in the long run. Impulsive actions, taking chances and those who feel that the customer owe them the business are losers who try to create an omnipotent feeling of bliss than realistic long-term success and are plagued by self-doubt.

It must start with what the customer wants and define all the actions based on clearly defined rules. You must structure your risk management plan so that the initial teething problems wouldn’t kick you out of the game. As you go past the honeymoon period, there must be a sound customer retention strategy to improve satisfaction and profits. For example, one study showed that a 5% increase in customer retention rate increases profits by 25% to 85%, but most of the time this aspect is overlooked by the management and their sole focus is to acquire more and more new customers. Sad to say, most of the companies I have seen do not have a solid Customer Life Time Value framework (CLTV). They have very little appetite to spend on improving its customer retention rates, customer satisfaction or customer relationship.

The concept of the long-term value of customers and the value of relationships is not new, but its not a core strategy in many of the IT services companies. Nobody wants to lose one of their largest, most strategic customers, but if you’re not investing in them properly and/or not providing the value they need, there is a real possibility that they will dump you, sooner than later.

No Code is better than “No Code”

I have a collection of technical articles that I put together in 2005-2008 period. I want to publish them through my blog. This particular one Inspire me a lot and the emergence of Low Code tools only reaffirm its relevance. An excerpt of the article that is published in the smart-techie magazine(2008 edition)

Higher wage costs in India forces IT services organizations to look at innovative methods to run the floor to deliver value. The uncertainty and fears may be rising, but there is a prospect of bringing back the old shine. The organizations find comfort in following what they were doing for long to build software, but in the changing scenario, it will be difficult to ensure business success unless organizations become more agile to adopt new methods to build software that will eventually address the people and cost factor associated with it.

There is No Code that is better than “NO Code“. Each time you increase the amount of code by adding more programmers, your software grows exponentially and more complicated. It also adds more overheads in terms of proportionate quality assurance, HR and so on. More time & money should be invested in identifying new methods to write applications that will help us in achieving high-quality code quickly and help customers lower project cost and time to market. With a unique combination of SDLC Boosters based on MDA (Metadata- driven architecture) and TSPC (Technical Statistical Process Control) companies would be able to reduce the overall project effort and improve productivity by 40 percent in building Business Applications.

When the traditional model dedicates 40 percent time for programming and another 20 percent for Q.A. metadata-driven approach demands only 20 percent in coding and the team spends more time on design and analysis.

Moving to a Metadata-driven development means that an organization will probably implement significant changes to their software development practices. But it’s worth the effort. One of the daunting issues of traditional practices is more programming and less of designing. A fully Metadata-driven approach means that the output of analysis and design goes straight into the software and there is not much code written. Therefore, moving to a Metadata-driven approach can provide a major benefit in terms of software quality and speed of delivery to customers. When thinking about executing models, most people inherently think about two options. One is code generation and another interpretation. Code generation is preferable since it is much simpler than interpretation and it is more testable and resulting code can be inspected. Whereas an interpreter is a (meta-) program that reads the model and executes code (algorithms, UI rendering) as it queries or traverses the model

With the changing business scenario, the usage of high-level abstractions in the solution specification makes great sense. We foresee the industry adopting DSL in driving quicker and better value to customers. DSL’s are poised to take on many of the challenges we have today, including the frequent requirement changes.