Biz app solutions

Some experiences and lessons learned

By Kinshuk Adhikary

Note : Slides not in any particular order, use own judgement in ordering them...

The user empathy elementIn one product, the most used region of the solution was a simple grouping of some names. Called MyGroup or something.

The developers would have spend less than a few hours in implementing it. Yet it was considered a “very useful feature” by most user groups.

● It is really hard to predict what user groups will find useful.

● The only way to get those into a product is to build a culture of “user empathy” in the technical teams, a sense of respect for the user.

● A certain amount of “technical humility” is a key to providing good solutions.

The domain expert

In a product related to pension funds, an 80 page document was created by a consultant, a real domain expert.

Without this, the implementation team had been foundering for six months. With it, the product saw its first version in the next four months.

● Before all else, domain expertise needs to be documented

● 10-15 years of actual experience in the domain helps

● Expert ought to also have been an user, in several user roles

● Describes not the product alone, but a 100 related things

It is about “content” , stupidMost business solutions are about the aggregation/creation of content, about content processing, and content delivery.

Seen in this perspective, the responsibility of the solution provider is a never ending cycle, not an end-point.

● Stop calling it “data”. Call it content, see how everyone's viewpoint changes.

● When you call it content, things like ETL, data migration, and user involvement from early stages come right up to the surface, instead of being after-thoughts.

● Content creation tools become a separate concern.

Architecture for the CxOThis was in the EJB 1.0 days. The CxO wanted EJBs, so he could compete in the market. The developers suffixed every class name like this, xyzEJB.java. And everyone was happy.

Without the CxO's developing an architectural perspective, it can be a rough ride. There are just 3 things to know (see below).

● Components – that do specific specialized things when instructed.

● Events – that cause a thing to be done

● Connectors – pipes through which the data and instructions flow between the components

The CxO is the most important person in the product. Without a diagram that he/she understands, the teams are lost.

We love to chatSo here is this amazing e-learning product, about a 1000 classes. And what do most users latch on to when it is in use ?

The Chat and Discussion module ! None of the pedagogy experts visualized the load on it, so everyone had to rush to refactor the entire module.

● Give users half a chance and they will love to chat, discuss, tweet.

● Collaboration modules are easily the ones that will see the most performance load.

User interfaceA good user interface has another name, it is called “habit”.

Whatever it is that user's are habituated to in other applications that they use, is what they instinctively look for in any new UI.

● Which obviously means the usual office applications and popular public internet applications

● The same or similar visual cues and legends; maybe only a few, very few departures, to signal a distinctiveness.

● An inventive creative UI is not the best way to make the user comfortable. In fact it can backfire sometimes.

Too much too soonInformation architecture is all about presenting the content in a way that users can relate to.

It is possibly the most difficult part of the solution.

● Too much text● Too much typing● Too many clicks● Too many fields on the form● Too many alerts● Too many pages to accomplish an unit of work● Navigation ● Drill down hypertexts● Page reloads● Tabular listings● Dashboard graphs and charts

Seems there is no easy way out except to find out the best fit.

VersioningSoftware is inherently iterative. Sometimes it is even recursive.

The versioning guy is the focal point of many things – features, marketing, testing, development, design, roadmap, furture(s)...

● Maybe not enough time is spent on discussing all the things that collect around that single thing called “version number”.

● Versioning granularity defines development maturity.

Meeting users physicallyDevelopers are human beings. They carry a picture of the users in mind after they actually meet them.

Users are human too. They love to share, throw bouquets or brickbats.

User conferences are a necessity and a need.

● Obvious. See also “Milieu of the developers”, a later slide.

Application securitySo you think your web application is secure ! Really ?

The lack of knowledge about the rudiments of application level security is amazing. Most well known public web applications are vulnerable in some way or the other.

I have also been quite put off that many many developers get into difficulties on authorization APIs like ACEGI.

● Checkpoint : Roles, Principals, Permissions, ACLs● Checkpoint : SQL Injection and XSS Injection● Checkpoint : HTTP basics● Checkpoint : many more, but at least the above !

A new generation of usersTen years ago, users would see an Error Page in your application, put a finger on their cheek, and say “Oh, how silly of me, I must have made a mistake.”

A new generation is around. They say things like “look at this stupid application, I actually have to move to another page to create a time entry !”.

● Just this – beware of silliness in solutions from now on.

● There is a “factor of unforgiveness” in the new kind of users, that ought to be somehow built into design, development and testing – but I am not sure how.

Intelligence captureAfter many years, one can almost instinctively point to 20% of a solution and say “herein lies the knowledge, the real intelligence”.

The remaining 80% are usually the mechanical parts. For a few dollars one can purchase tools and jigs and fixtures that would make creating that 80% a simple task.

● When one sees such intelligence not in a pin-pointed location but generally scattered, it is a red flag.

● In that case, instead of a lego toy, it is probably a noodle.

● Noodles affect the enterprise in many cost-ineffective ways.

Meeting the future with the solutionSooner or later, a solution comes up against a fairly common set of concerns.

How much easier would things be if these were considered right at the beginning, considered, not necessarily implemented.

● Entity models and hierarchy● Data migration● Identity management● Integration issues likely to arise● Reports● Push-pull-publish-subscribe● Load distribution● Goes on and on...

Quality firstsMost development teams do not have structured testing approaches or test teams.

Most pay lip service to unit testing – they think it is something that testers do.

And most important, the idea that quality comes from early and informed interventions by the “first people”, a set of good architects and design guys, is a rare thing to find.

● Quality arrives from a sales and marketing perspective

● Quality in software is very similar to the interactions between a good publisher, an editor, and an author.

● And of course, the book in the hands of the user.

Agile's achilles heelAgile methodologies seem to be modelled on the request-response paradigm. To quickly create something that is just good-enough. To use recursive small iterations to create a product.

Small jigsaw puzzles, yes. Complex ones, no. It is not possible to increase complexity, completeness and consistency by simplistic assumptions. The “whole” has to be visualized before the “parts”.

● Think of a problem space as a “big bug'.

● It is about disintegrating the big bug into small ones, and controlling the number of secondary bugs as you put all of them into a box.

● If you cannot see the roadmap, you cannot control the bugs.

Where is the customer ?One of my most hilarious moments was with a couple of guys building what they called a “Billing module”. To create bills for hours worked etc. To be sent to customers. With aged bills.

But the application, a superb one about the “work” itself, had no concept called “customer”. At the modelling stage they had somehow forgotten that a customer, explicit or implicit, was needed in a billing scenario. And introducing one now would change the models quite a bit. Red faces everywhere.● Amazing things happen. And a camel is a horse designed by a committee

● A few years ago, an enterprise level software nearly bought a company down. Someone had improperly priced “goods-in-stock”, so the software always showed slightly lower inventory. The problem was traced to its root cause only after a slow Christmas sale and contradictory “buy” instructions led to the company's warehouses getting flooded.

Milieu of the developersFor business solutions, it is difficult when the development team lives and works in a space that is too different from the real business environment.

Consider a brilliant student or intern who has only a theoretical concept of a workplace. There are only certain kinds of problems that can be tackled by such a person.

This understanding lies at the root of a successful distributed development environment. How to send work out, and then collect it back in.

● Comprehension is the first benchmark of communication.

● Constructive feedback is the second.

Effort estimatesMost of the talk about estimating software efforts in terms of man-hours and people is actually quite ridiculous. Consider :● Pieces that used to take a month of effort about 6 years ago, take a few hours nowadays with the right tools and IDEs.

● Not knowing all this, and asking the developer to estimate the effort, is like asking the barber if a haircut is needed.

● In most teams, there are only a few among the large hordes of them who (can) make a large difference. Some developers can deliver 3 times as much as another, or 10 , or even 15.

● There is no fall back, there is no “replacement for a person”. There is nothing called knowledge transfer. When a key person leaves, a new project silently replaces the older one, with few able to differentiate.

● Elapsed time is not a mutable variable.

St. Paul's Cathedral on a clear moonlit night

There are only very few architects.

The distance between them and the implementors is vast.

Their relationship with the business folks is strange too.

They can be “commissioned” by a patron, not really hired by an employer.

When all these gaps are bridged, you get a cathedral that outlasts the flux.

It is NOT about engineering alone.