Category Archives: Engineering

Engineering, Innovation

Technical Debt Assessment framework for Product Managers

2 Comments

a.k.a. Why & How Product Managers must assess, account & groom technical debt

Context

Technical Debt explained (c) galorath.com
Technical Debt explained (c) galorath.com

When I started conceptualizing a new product 5 years back, the concept of technical debt only existed in theory. Over a period, the pressure of time & customers, drove features cuts, compromises, and unfortunately, some quick-and-dirty solutions. Post the short-term wins, its not too long before technical debt surfaces and forces a resolution.

Triggers

Technical debt is taken up for short-term advantages such as shorter time-to-market, and preserving capital. But in the long run, it reduces productivity, time available for new feature development and, God forbid, might keep you from crossing the chasm.

While Product Managers balance out the short and long term benefits/impact of every product decision, it is important that they keep track of the debt that is being baked in with every story. At the same time, having some framework to preempt the debt that is inadvertently introduced and proactively manage it as a roadmap item.

The Debt Assessment Framework

Fowler categorizes debt as Reckless v/s Prudent, or Deliberate v/s Inadvertent. While this classification answers the ‘how’, it doesn’t provide visibility into ‘what’ and ‘where’ of debt is added. Without further classification, accounting debt is like having a balance sheet with just one account for liabilities. I would like to further categorize all the debt that is deliberately added and assess its risk upfront. Here’s how:

Risk assessment for (deliberate) technical debt
Type Potentially lacks.. User Visible Sales Risk Ops Risk
Business value Comprehensiveness in all business scenarios, Browser/Language support, Super admin rights, etc. Y Y N
User Experience Simple task flows, help cues, consistent design, mobility, Usability or A/B testing Y Y N
Performance Quick response, High availability, Clustering, CDN, Load/Stress test suite Y Y Y
Maintainability Data redundancy, Recovery, Migration, Configuration management, Sizing estimates, Documentation N N Y
Design/Architectural Portability, Modularity, Coding standards, & styles, Web services, Latest component versions; Has glue or duplicate code N Y Y
Test Automation Comprehensive coverage of functional/unit tests, either brittle or missing N N Y

If you’re wondering why (missing) features and defects don’t show in the list, that’s because they are the fundamental work units for development and not actually debt.

Practical use

Using the above framework as checklist for all new feature development, even non-technical Product managers can easily assess Continue reading Technical Debt Assessment framework for Product Managers →

Being a Product Manager, Engineering

Top 3 configurability needs in B2B apps

Leave a comment

What is configurability?

Configurability is the ability to change application behavior (functionaility) and the interface by changing application parameters, without the need to rewrite code. This can either be done in the front-end by users, or through back-end configuration. On the other hand, customization requires making change to the application code to modify existing or support additional requirements. Sophisticated application design (e.g. web hooks) can permit customization by externalizing the new functionality. But modifying existing functionality in a multi-tenant application is really not advised.

Top 3 / All-time favorite requirements

  1. Web forms / Custom fields: Customers may require the flexibility to add additional fields to a particular document/record (object). Moreover, there would be a need to validate the input to the field based on data-type, or a script. For example, tenant A may require tax-ID as an additional integer field on the customer information object, and also make it a mandatory input. This has grown to be complex enough to support attachment fields, link to master data, controlling access to specific roles/user, etc.
  2. UI customization: Customizing the user interface involves matching the look-and-feel with the customer’s branding: corporate color scheme and adding their logo. Allowing users to customize their own data views (record lists, reports) is just assumed to be there. Sometimes controlling data elements could also be a requirement. (E.g. End-users wont know certain information, so a section needs to be hidden for them. But the next user in the workflow Continue reading Top 3 configurability needs in B2B apps →
Being a Product Manager, Engineering

Why PMs should consider product configurability early on

Leave a comment

I am sure that the way I have configured my mail client or tablet’s home screen is different from yours. The reason we love modern-day apps and operating systems is because they let us configure the product to match our specific needs. Configuration is not a new concept – even old radio transformers allowed listeners to tune into the station of their choice without having to open any screws. Configurability isn’t a feature; its a vision. And it doesn’t come free; too much of it will also backfire. There are at least 3 compelling reasons why product managers need to plan configurability around every feature:

1. Customization

No product is designed for a single customer. And it would be rare that 2 customers had similar business processes. To adapt to the difference, without having to create customer-specific code bases, an application needs to be customizable. Gone are the days when customers would 200% of license fees on getting the product customized to match their business needs. In today’s scenario, solution providers need to cover the cost of customiztion through one-time implementation fees.

2. Rapid Implementation

Besides, customers are not looking at multi-year transformation projects with huge budgets. Project managers need to create compelling business cases and promise hard dollar recovery through the proposed solution. Every project is like a turn-key project and a vendor has no chance unless they can promise rapid implementaiton and unlock the RoI in stipulated time. Continue reading Why PMs should consider product configurability early on →

Engineering

Choosing the best web application development framework

Leave a comment

I’ve discussed web frameworks before and how they can help in rapid development. In this post, I’m presenting some general guidelines around selecting the best web development framework, based on your requirements, in the the preferred language: Java, Ruby, PHP, Python. The main criterion is evaluating the non-functional requirements it provides out-of-thebox, which can greatly aid rapid development.

What to look at in a framework?

You should know how the design considerations mentioned below are addressed by the frameworks you are evaluating. Depending on the business needs, some might be redundant, but tend to provide a holistic view of the framework’s capability.

  • Scaffolding code: What is the ETD to get a web-form with basic CRUD running?
  • Does it offer the flexibility to choose between convention & configuration?
  • How is input data validation achieved?
  • Is the View layer simplified with a template engine?
  • Does it employ object-oriented design patterns? and demand OOP?
  • Does it follow MVC (Model-View-Controller) pattern? How is routing (URL management) achieved?
  • What ORM tools (object relation mapper) does it support?
  • Does it have built-in support for multi-tenancy?
  • Does it support I18n & L10n out-of-the-box? (Internationalization & Localization)
  • How is Authentication & Authorization managed: inbuilt, using a module or plug-in?
  • Does it allow rapid development/deployment in line with Agile principles?
  • Are there cases of proven success for enterprise class applications?
  • What is the performance benchmark vis-a-vis other frameworks?
  • Is there in-built support/plugins for caching, unit & scenario testing?
  • Is it easy to debug applications, and if possible with in-built support through an IDE?
  • Associated costs & TCO: to build developer & infrastructure expertise, hosting, licensing, support?
  • Does the licensing permit free use for all purposes and the right to modify code as necessary?
  • Does it have a clear product roadmap, sufficient documentation & an active community?

The decision

Don’t get carried away by flashy white-papers, classy developer events or generalized case studies. Your application is going to be different (a reason why you’re building that product in the first place) and while it is good to use guidelines, you need to see what fits your requirement best. Take a weighted approach to evaluating a framework based on the evaluation criteria above and make sure you have enough reason to be convinced.

This post is part of the SaaS Application Development series, extracted from my final dissertation submission at BITS, Pilani that closely looked at rapid-development of SaaS-based applications.

Culture, Engineering, Gadgets, Thoughts & Opinions

Everything has an expiry date – except software?

Leave a comment

I was having a discussion with my friend/colleague Amit Shinde about the quality of things, and he brought up this topic of expiry dates. Fortunately for us, here in India, we now – at least – have an expiry date for most food stuff sold on the primary economy. The underground economy – or System D as it is known – is so vast and so uncontrolled that the government cannot even dream of regulating it.

But Amit’s concern was much beyond perishables. He mentioned his iPlugs for example (I’m not a Apple guy and don’t know if they call the iPhone earplugs that). He said that although there was no visual damage, they weren’t performing as they did. After all, everything has a shelf life – which may or may not be straight-forward to predict.

Take vessels for example. The old copper & brass vessels – now costly souveniers – have served families for years. There even exists a maintence process to extend its life. But the non-stick we use today in our fast lives is not built for centuries. Who knows how the coating disintegrates or how the lower layers react with oil/soap. I’m sure there is a point at which it has to be discarded – which is left to the consumer’s discretion. And when it comes to Indians, experimenting overage tolerances on expiry dates

Continue reading Everything has an expiry date – except software? →

Engineering

Rapid application development & web frameworks

Leave a comment

Rapid Development

Over the last decade, there has been a massive growth in the number of web-based applications. For every category – email, collaboration or knowledge management to name a few – there are a large number of applications available, and new ones on their way. This has created extreme competition in the market with each application claiming to be better than the other. Even if a new concept exists that is strong enough to drive the market, time-to-market is a crucial factor that will decide the success of the product.

To address this, a rapid application development strategy needs to be in place so that the product and incremental features can be delivered at the expected rate which is dictated by the market & customers. Besides this, development needs to also follow an agile model so as accommodate ever-changing business requirements. This is especially true in the case of product development, where a single product must fit multiple customers with varying business requirements, and the classic waterfall model can lead to complete failure.

Web Application Frameworks

A web application framework (‘framework’ hereon) is a software framework that is designed to support the development of dynamic websites, Web applications and Web services by providing core, non-functional features out-of-the-box. A framework streamlines application development by automating many of the patterns employed for a given purpose and thus resolve the overheads associated with common activities performed in web development.

A framework also adds structure to the code, prompting the developer to write better, more readable, and more maintainable code. It promotes code reuse through the use of libraries for database access (using ORM), template engines, session and user management, logging, internationalization, etc.

Framework selection (we’ll elaborate this in the next post) is thus crucial in delivering the required functional & non-functional requirements within stipulated timelines. Non-functional are the primary influencers Continue reading Rapid application development & web frameworks →

Engineering

Definition of Multi-tenancy

Leave a comment

Multi-tenancy was a relatively new concept back in 2010 when I was writing the dissertation report for my MS. This extract from the report aims at providing a clear understanding.

Multi-tenancy is an architectural pattern in which a single instance of the software is run on the service provider’s infrastructure, and multiple customers, or tenants, access the same instance. It is an organizational approach for SaaS applications today. SaaS-based software providers are believed to have evolved from Application Service Providers (ASPs) from the previous decade, which differ from today’s multi-tenant applications which are provided via a software-on-demand model specifically designed for SaaS distribution. Although the interest in this concept is rapidly growing since its inception in 2005, research is relatively slow.

Key aspects of multi-tenancy

  • The ability to share & optimize the use of hardware resources
  • The ability to offer of a high degree of configurability
  • The architecture to support the use of a single application and database instance to serve all tenants
  • Cost benefits from economy of scale & improved utilization
  • Ease of deploying a single instance
  • Simpler management
  • More frequent releases with bug-resolutions & new features
  • All customers are upgraded at once
  • Reduced operational costs
  • Easier to scale-up with the advent of cloud computing

Benefits of multi-tenancy