1. Socially Cooked Software
A talk on software,cooking and other stuff...
Chris Spiliotopoulos
Software Solutions Architect

2. Software vs cooking
● Software development is
like cooking
● Good ingredients = Fine
taste
● Many companies create good
software
● Some create great software
● But when it comes down to
excellency, just a few players
can handle it

3. The taste industry
● Every player tries to make a difference
● Everyone wants to make money
● People bring money -> companies
need to attract LOTS of people
● That's why food is everywhere - TV,
radio,internet, etc
● The industry needs communities to
target products
● Communities define the taste game
● The industry has to keep up with the
changes

4. The software industry
● Exact same rules apply
● Companies strive to find communities
and make a difference
● Sometimes they even have to invent
them
● It's a WAR out there...
But wait...! this is not a
personal war anymore...
● The game got social now...
● And communities make the rules
● This is why communities are now
OUR business

5. The rules of the game
● Communities need software
that covers their needs and interests
Software should be:
● fun
● easy-to-use
● consistent
● engaging
● interactive
● collaborative
● memorable
● productive
● modern

6. But what really makes the difference?
● One game - many competitors
● Ranging from small companies to multi-national ones
● Thousands of new social apps are out every day
● But how many stand-out and last?
● Just a few...
● Not a matter of quantity
● But a matter of QUALITY
● And as in cooking...
○ millions of recipes
○ but classics are always classics!
● Quality and finesse always make the
difference

7. Software as a service (SaS)
● The download-n-install model is
sooo last year...!
● Software is now being
served...
● And service should be of the
highest quality
Now the customer gets to choose
from a service catalog - this catalog
should be:
● up-to-date
● expanding
● innovative
● precise

8. The actors and their roles
The company (as the restaurant)
The teams (as the cooks and chefs)
The products and services (as the
foods)
The communities (as the customers)

9. The services catalog
● Starting from now, the company will create its own menu
● The concept is to start creating an ecosystem of products
and services
● This ecosystem will be presented to the customers
● The customers will be able to mix-n-match components
and services for building on-line communities
Our services menu should:
● satisfy different customers
● accommodate different needs
● be our trademark
● be our facade within the market
● become recognizable

10. Products and services
● Customers will choose us
because we provide something
they really need and
is differentiated ● REUSABLE
● So far, we conformed to the ● High-quality
customers ● Extensible
○ gaining experience from ● Pluggable
project requirements ● Standardized
● Now it's time for the customers to ● Internationalized
conform to our catalog ● Fresh
● This way, our services are ● Innovative
standardized and we expand our
catalog when multiple requests
for a new service are gathered
(or when we think of something
cool)

11. How things should work
● Every successful restaurant owes its success to its people
● Keys to success:
○ Organization
○ Separation of concerns / fields of expertise
○ Standardized procedures
○ Automation
○ Co-ordination / orchestration
○ Roles & responsibilities
● We should try and mimic the restaurant model and split
people into different teams with well defined responsibilities
and expertise
● In order for things to work, people should know what they
are/must be doing and follow some rules.

12. The restaurant model
Pastry
Food Grill/Fish
Quality &
taste control
Garcons Service
Sommeliers

13. Translated to software production
R&D Products &
Art & Services
design
Projects
Q&A System
Testing
Communities ● Many roles, different
levels, but 1
communication language
● The services menu

14. Everything is a service
● The single measurable unit of production is the service
● We should ALL start thinking in terms of services, rather
than projects
This way,
● the sales team will sell services and bring in requests for
new ones
● the marketing team will conceptualize services that
extend/leverage existing ones
● the Products & services team will implement services into
functional software components
● the R&D team will create new technology to provide added
value and enhance our services
● everything will become simpler and cataloged - so that
everyone knows what exists and how to use it

15. Our own components ecosystem
● The ultimate goal is to have our own
ecosystem of components that will
make a difference
● Similar to a restaurant menu, it should
cover different tastes/needs
● Ideally, components should be able to
communicate through standard
services and leverage each other's
functionality
● Should be treated as a puzzle that
needs to be filled - components are
pieces that interconnect
● A tight ecosystem will bring tight sales,
as the need for other/new components
will always be around

16. What is a component?
● A software module with well defined behavior
● Implements business functionality through services
● The building block in a Service Oriented Architectured
(SOA) ecosystem
● Implements one or more business services
● A component should be:
○ self-contained
○ generic
○ REUSABLE
○ internationalized
○ testable
○ documented
○ pluggable/extensible
● Components are the deliverables, i.e. what the customer
gets at the 'table'

17. Production lines
● 3 major production lines will be formed:
○ R&D
○ Products & services
○ Projects implementation
● These lines run in parallel, but have integration points - all
teams should be up-to-date with each others work
● Specs for new products and services are usually introduced
by the business teams
● Products/services team identifies new services & components
to be implemented
● R&D and Products/services should collaborate
● Projects team mix-n-matches components to deliver
communities as requested by the customers

18. Separation of concerns
● Different teams should have different responsibilities
● Knowledge should be exchanged (where/when possible)
● But within the company teams, expertise should be split
between people
● Remember the restaurant model? Different chef for different
types of food/pastry.
● This is good because:
○ You know who to ask for something
○ People exploit their creativity
○ Right people for the right job
○ Quality is sustainable
■ different people have different taste when doing things
■ difficult to communicate and agree on everything

19. Development workflow
● Should be standardized, so every team knows &
understands the procedure
● Development SHOULD be driven by design
● Components must conform to the guidelines that will be
provided
● Behavioral specs will be provided with the initial design
● QA & Testing will become an integrated part of the
procedure
○ QA team is responsible for behavioral,business and user
experience quality control
○ Testing team is responsible for unit/stress/load/integration
testing
● SCM, build and versioning procedures will become
automated

20. Standards & guidelines
● No need for us to re-invent the wheel (at any level)
● We should learn from the leaders in different fields
● Guidelines should be simple and consistent - should be
helpful and NOT confusing
● Should not restrict our creativity but remind us of mistakes
others have come across in the past
● Will help new team members to move forward to production
mode faster.
● WE define our standards - should be voted in a democratic
way - every opinion counts, so everyone should be involved
● Standards will protect the quality of our software and
services - as long as we stick to them

21. How do we make the transition?
● We will start by creating some initial components & services
● The ecosystem will start to take shape
● Then guidelines,standards & procedures can be
documented, from individual teams, e.g.:
○ Products/services will provide guidelines on how to
develop components and services
○ R&D on integrating with their modules
○ Art&Design on themes, UI and look-n-feel
○ QA & System testing on behavioral,user experience and
acceptance
● It is impossible for everyone to get involved at this stage
● A few people will take the initiative at first and then the rest
will follow

22. How do we make the difference?
● Good ingredients make great
dishes
● We need 3 key ingredients:
○ Quality
○ Simplicity
○ Imagination ● Nowadays simplicity is a
synonym for elegance
● People want simple &
practical applications - no
rocket science!
● Improvisation makes the difference in
cooking - and in software!
● Re-usability combines all of the above:
○ Same ingredients -> different taste
combinations

23. It's all about style!
● We have opened a door to a global market
● This a unique chance for us to make heads
turn...and get noticed
● This is why we need our own style
● Our components should stand out of the
crowd,be memorable and indentifiable
● Art&Design will set the standards and all
teams should follow some consistency rules
● All components should have a similar look-
n-feel and provide standard user experience
● Users do not like changes - they have a
preference... and stick to it

24. Time to get social
● If we want to play the social game, we
need to understand the user's first
● What are their needs and how do they
think?
● This social vibe must exist within the
teams as well - team members should:
○ collaborate
○ socialize
○ discuss / argue
○ improvise
○ share knowledge
Because eating alone isn't fun...

25. Environmentally friendly products
● Quality products and services are
adaptive to environmental changes
● Good software design should follow the
Java philosophy:
○ Write once, run everywhere
● We live in an era where cross-platform
software is the trend - and the reality
● Components should be generic enough
to work on different containers and
platforms
● Front-end modules should be cross-
browser ready
● This way we DO NOT leave use cases
and prospects out

26. International Cuisine
● By hitting the global market, expect
international customers at your door
● All of our products should be i18n
ready (internationalized)
● This means that all textual messages
should not be embedded into code,
but externalized into separate
resource files that can be translated
● Apart from Greek, English should be
supported and other languages can
follow

27. So, you think you got traffic uh?
● Going global brings other sorts of issues
as well - traffic is a major one.
● Depending on the case, internet apps
can have a variable amount of
users/requests per sec
● Component specs should predict this
kind/rate of usage
● Components should be thoroughly tested
by the Testing team for tolerance under
extreme load/stress
● Therefore services exposed by
components should be testable and well
defined/documented
● Tolerance+endurance = quality

28. Open minds, fresh ideas
● Technology is meant to be explored
● We should always think "outside of the
box"
● Do not be afraid to experiment
● Try new things, fail and then try again
● Technology is evolving day-by-day and we
should not stay behind
● Share your ideas with the rest of your
team mates
● What we think as dumb, sometimes can
lead to great innovations
● Companies that make innovations are no
better than we are - they just take the risk!

29. Performance
● Components should be scalable
and optimized
● Development should be done as if we were
working on a Spectrum and not on a 4GB
Pentium
● Respect your resources and they will
respect your user
● Components should be light-weight and
responsive
○ Sloppy UI leads to frustration
○ Use modern techniques for partial data
fetching and refreshing
● Fine tuning is the enemy of good design -
do not leave it for later... do it during
development

30. Summing up...
● Success is not in winning the game...
● Success is in making people happy
○ community members
○ customers
○ company teams
● The social game cannot be won - players
just leave their mark, either big or small
● We should try and have as many people
as we can to try our food
● And our goal should be just one...
Leave a good taste in their mouth!
Thank you!