The document provides an overview of similarities and differences between academic and commercial software development. It discusses types of software like bespoke vs product-based and their complexities. Key factors in commercial software sales like convincing decision-makers during demos and end-users during daily use are outlined. Important aspects of making software sellable like always considering the customer, focusing on aesthetics, and frequent releases are highlighted. The role of the developer in maintaining quality, using mainstream technologies, and not becoming too specialized is also discussed.

1. ahead of one’s time
Academic and
Commercial software
Development
Similarities and Differences

2. Tom van Ees
 CTO Davinci Products
Experience
 29 years in software
development
 Specialties: product innovation,
software development and
solution architecture
Introduction speaker

3. Introduction
Davinci
Introduction of the topic
Types of software and software solutions
Customer
Decision making factors for buying software
Buying software - what matters but often stays under cover
Decision makers vs. end users
Sales demo vs. daily experience
Software
How to make sellable software
How to look at software and the solution
What does matter - functionality vs. look & feel
Customer awareness - customer needs vs. technical aspects
Tools, libraries, plugins - help vs. restraints, make vs. buy
Developer - what you should keep in mind
First time right
Things you should always keep in mind (security, performance, scalability, etc.)
Being specialized or try to know all – interdisciplinary
Agenda

4. IT organization founded in 1991 with over 180 employees
Based in Amsterdam (HQ) Hilversum, Barneveld, Antwerpen (B),
Bratislava, Žilina (SK)
Davinci Consultancy
Davinci Products
Products: Document analysis, Process Automation, Data
Quality, Mortgage Fraud Detection
Davinci Ventures
Introduction

5. What is the difference between software development in an
academic setting and software development in a commercial
setting?
What does it take to be able to sell software once and what does
it take to be able to sell software many times?
What is the role of developers in this and what will be required
of them?
Questions of the day

6. Types of software... Bespoke vs. Product
Bespoke
You make a detailed design together
with one customer what the
software should do for that
customer and you discuss the exact
infrastructure in which it should run.
You determine a price and you build
and you get paid. As easy as it
sounds, this is a difficult process.
Product
You make a detailed design, trying to
imagine what all customers in your
market want and what different
infrastructures they use. You invest
upfront, you build and you hope that
you earn enough to make a profit
(hockey-stick effect).

7. Types of software... Simple vs. Complex
Algorithmitically Simple
Personal DVD administration
Algorithmitically Complex
Data analysis, Document analysis,
process planning
15-5-2014 7
Infrastructurally Simple
Limited amounts of data, limited
number of users, limited security
requirements, limited performance
requirements and limited
robustness requirements
Infrastructurally Complex
1000’s of concurrent online users,
10’s millions of records in database,
sensitive data and the requirement
of sub second respons times and a
system that must never fail.

8. Types of software... End User oriented or topic oriented
End User oriented
It is assumed that the software is
built for/adjusted to the end user
Topic oriented
It is assumed that the end users
adjusts to the software.

9. Types of software... Simple task vs. Complex task
Simple task
One screen to enter the car
registration number of every car that
passes.
Optimized for that one task, limit the
number of keyboard presses to an
absolute minimum
Complex task
Evaluate all documents a customer
sends to you in terms of correctness
and potential fraud
Give full flexibility to look at the
problem from all directions,
compare things, make notes etc.

10. Similarities and Differences
Academic Commercial Davinci
Bespoke/Product Bespoke Both Both
Algorithmic complexity High to very
high
Low to medium Low to very
high
Infrastructural complexity Low to High Low to High Mid to High
User/Topic Oriented Topic User User
Simple/Complex tasks Complex Usually Simple Complex

11. CUSTOMER

12. The people who decide to buy software are not the people who
will use the software day in day out, 8 hours a day.
Those decision taker needs to be convinced during the pre sales
(RFI, RFP, demo) phase
The end-user needs to be convinced every day from the day
software is installed until they retire, get another job or force the
organization to buy from your competitor
The decision takers and the end-users together are the
CUSTOMER
Who is the customer?

13. How do organizations buy software products?
RFI to long
list
Reduction
to short
list
Demo RFP Evaluate Negotiate Decide Implement

14. People who decide: Decision making unit (DMU)
 The problem owner
 The money owner
 The IT manager
 They all need to be satisfied!
 They all have contradictionary demands!!
 They all try to enforce their own demands!!
How do organizations buy software products?

15. Key question areas
Problem Owner
 Does the software do what I need it to do?
 Could I do it myself? (even if they are never going to use it themselves)
 Is it easy to use?
 Can it fit the way we are working or want to work?
 Is it efficient, flexible?
 Is it spectacular?
Money Owner
 Is there a cheaper solution?
 How can I negotiate cost reductions?
IT Manager
 Does it run on my DBMS, my OS?
 Do I need to train people?
 Do I need to buy more products or can I stick to one product?
 How much effort to manage the product?
 How do I integrate it with other systems?
 Do I have previous experience with this vendor?
 How is support organized?
How do organizations buy software products?

16. Adoption of software (artist impression)
Adoption
Demo
Actual use
Major bug
Min. Adoption
Level
New Release

17. Customer does not understand how the software works
Does not run on preferred infrastructure
Demo does not demonstrate what customer wants to see
 Typo’s, unlogical layout, unlogical application structure, technical
terminology
 Too technical, too nerdy
 Unable to translate customer daily practice into the demo
 Not understanding the customer’s business
Unclear cost-benefits ratio
 Why does this software cost so much?
Major dissatisfiers for the DMU

18. SELLABLE SOFTWARE

19. Be always absolutely, totally customer aware: designer,
developer, sales, support
It is not just functionality, the looks are as important
Offer very good functionality using mainstream technology
Deliver frequent new releases with relevant improvements
What is not on this list: Software architecture
How to make sellable software?

20. You (the developer) are not the role model for the end-user
For every user type invent one or more personas
 With a name, an age, a gender, a photograph
 With an education level
 With a certain amount of experience
 With a certain atttitude towards work
 With certain objectives in life/work
Check whether the personas are realistic
Even if the development organization does not use personas, you can do it in
a very informal way
 Your father, mother, uncle, neighbour
And with every decision you take, think about how each persona would
decide and how each persona would be impacted.
Customer aware: personas

21. Personas

22. During a demo the aesthetics are as important as the
functionality, because not all functionality will be seen during
the demo. But the looks of the application is in the face of the
customer all the time.
Aesthetics is not only colors, layout and dimensions. It is also
about elegance of use and the way the software models reality
Looks and aesthetics

23. Innovation vs. Costs vs. Fitting the customer as a
glove (ref. Treacy & Wiersema).
Innovation
 Always be ahead of the competition, research, vision:
define the market
Costs
 Always have the lowest price for the same
functionality
Customer fit:
 Bespoke development, highly configurable
Functionality

24. Have new releases available like clock work in
order to keep the adoption level high
 Product road map
 Product release train
Release Management

25. DEVELOPER

26. We build this cool application in ‘Befunge’ with a distributed file
system for the data which we put in morse code.
While the IT manager just wanted an application that runs on
the Microsoft stack or the java stack with a relational database
(SQLServer or Oracle or DB2).
Mainstream technology

27. Software Architecture is important for you and your organization
(continuity), less so for the customer!!!
Building software in a commercial setting means that the less effort is
required and the less mistakes are made, profits will be higher
But focusing on costs only does not produce sellable software
Use best practices in order to solve similar problems
“When we had burned all money, we had a very beautiful
software architecture and a kick-ass database, but a very
crude user experience. Then we went out of business”
Developer: Cost of development

28. Some quality aspects are difficult to realise.
 Complex algoritms will always contain mistakes and need
to be tested extensively and improved. That is totally ok.
Some quality aspects are very easy to realise (First time right)
 No typo’s, decent screens, informative feedback
 Basic database performance aspects (proper logical and
physical modelling)
 By definition Implementation of standard security best
practices
Developer: Quality awareness

29. Java/.net with relevant frameworks
Databases and data modelling
XML
Script languages
Relevant java frameworks
Security related frameworks
etc
“If your only tool is a hammer, all your problems start to
look like nails”
Maslow
Use the tools that best fit the problem and do not become a
one-trick pony, given for whom you are building software
Developer: tools of the trade

30. Thank you