Some experiences and learnings from building business solutions an products.

1. Biz app solutions
Some experiences and lessons learned
By Kinshuk Adhikary
Note : Slides not in any particular order, use own judgement in ordering them...

2. The user empathy element
In 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.

3. 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

4. It is about “content” , stupid
Most 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.

5. Architecture for the CxO
This 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.

6. We love to chat
So 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.

7. User interface
A 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.

8. Too much too soon
Information 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.

9. Versioning
Software 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.

10. Meeting users physically
Developers 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.

11. Application security
So 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 !

12. A new generation of users
Ten 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.

13. Intelligence capture
After 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.

14. Meeting the future with the solution
Sooner 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...

15. Quality firsts
Most 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.

16. Agile's achilles heel
Agile 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.

17. 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.

18. Milieu of the developers
For 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.

19. Effort estimates
Most 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.

20. 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.