Monday, January 15, 2018

The Art in Modularity


Good software developers tend to be organizing freaks: everything goes in a tiny little box in its proper place. You know the saying “there’s no limit to how complicated things can get, on account of one thing always leading to another.” This is especially true in programming.

To combat this creeping complexity we strive for modularity and maintainability. A small module that encloses a specific business rule is easier for testing and allows for greater flexibility of reuse. When modules become too small however, the sheer act of tracking them, organizing their use, maintaining consistent versions, and finding where a business rule gets implemented interferes with your productivity.

Somewhat counter-intuitively smaller modules also need greater external documentation, mainly to track the nature of the parameters passed between them.

What’s the right size for a module then? And how many modules should a system have? Although I like a module to be between a half and five printed pages it really depends upon two things: how many people are maintaining the software and the density of the development language.

The fewer the number of developers the larger modules can be. Each of you is baking your own cake. So if it’s just the two of you maintaining a legacy billing system written in an old dialect of Basic (that gets about as complicated as a GOSUB and a CALL) then sure, go with the 5-page modules.

But if a half-dozen of you are planning to maintain ASP web pages in C# (with overloads and inheritance) then you’d better veer closer to the halfpage module size. In that case you’re not each baking a cake; you’re all contributing to building a car. You need to be able to swap in new replacement parts when the old ones wear thin. Every once in a while step back to review how you are developing the code: are you using appropriately sized modules?


Friday, December 15, 2017

Artful Tool Use


A work acquaintance once posited “if we have the stupid people develop it, then it will be easier to maintain. If the smart people develop it then only the smart people will be able to maintain it.”

One of the classic management dilemmas remains how to select the creative workforce for a long-term project (or in software a neverending project) such that the system will not only stay maintainable but that the developers can accomplish the project in a subtle and efficient manner. It’s rather a deep question.

Your philosophy towards tool use and the Development Lifecycle may precipitate how you answer this question correctly in your surroundings. Imagine a chart with company strategy on one axis and expected system longevity on the other axis. Then we should ideally expect the mix of tool use and the level of employee expertise to look something like this:


Legend: HT = high tool, ME = medium expertise

At first glance this chart makes little sense: the ranges of expertise and tool use jump about and seem to lack any expected sort of gradient. This is attributable to the two dominions for when tools make a good bet: first when getting a system out fast has high strategic value, and secondly when time or money are likely to constrain your resources.

Similarly two situations require a higher level of expertise: when a system has a very specific focused utility and when the company needs the software to survive an expected future path of high business volatility.

Choose your tools and your creative workforce to match your company’s strategic plan. This is a key goal of I.T. strategy alignment and helps to avoid the dreaded swamp monster of impedance mismatch.


Wednesday, November 15, 2017

The Art in Empathy


The continual empathy of your clients is a key component of analysis. A separate entity from your sponsor, the clients are the people who will directly wield your software. Sometimes these folks overlap with the people who paid for the development and sometimes they don’t. Regardless you would do well to heed your clients’ desires as in the long run the clients keep you employed, rather than your sponsor.

This may strike a slightly odd chord, but it is akin to pointing out that you are more accountable for keeping your car running than the bank that lent you the money. All the bank cares about is that their loan is paid back with interest. But you will be the person driving your car and how you care for it and drive it determines how long the car will last. Similarly how well your project meets the needs of your clients will determine how long your software stays useful, even though your sponsor is providing the financing.

Amazingly enough the client enjoys relating their desires to someone who expresses a genuine interest in their needs and their working environment. You should try to discover what keeps the client awake at night: what are his worries. Nothing pleases a client like a designer who knows his workday life in detail, his daily routines, and what he faces in the way of competition and challenges in his office.

Analyze the big picture, not just the snapshot relevant to what you perceive as the scope of your project. Anticipate what the client wants: don’t wait for them to ask. Finally in those instances where you’ve identified a can of worms without a ready solution, consider what alternatives are available to monitor, mitigate, or manage the issue.

Interviewing for requirements seems simple enough, yet actually listening to a client discuss his desires takes a considerable amount of insight. You need to understand the sociology of his office and the things he wishes he had but doesn’t know how to ask for. Many times an employee is shy to relate his frustrations after finding that doing so in the past only set him apart as a complainer. You need to commiserate with him (without being smarmy or condescending) and then step back and independently think of ways to improve his working life.

Design extends beyond its up-front activity: once you’ve installed the initial version of your software you need to revisit the client to assess the full impact of your creation on his daily activities. The artistic thing to do is to create a system that your client appreciates long after you are gone. Continued empathy is the key for doing so.