When going into the development of a software product, a possible source of mistake is the incorrect evaluation of the complexity that lies behind an idea , as well as a clutter coming from the massive amounts of technologies enabled. This presentation explains a possible way to deal with such issues.

1. Binary Crosswords
http://www.laurentcerveau.org
lcerveau@nephorider.com lcerveau@mmyneta.com

2. • Last time we talked about hiring an engineering
team
• No we talk about creating a product with this
team
• I do not pretend to give a top notch description
of all technics mentioned here.
• In fact this is even be the opposite. This is not at
all the purpose of the talk
• So again a manager oriented thing :-)
We start where we left

3. • You have ideas/specs/people (3)
• You ask around for all the best tool and
technologies…a little bit
• You still want to believe technical development
is deterministic
• You have read a book on how it works
• Your planning is so that you will get investor with
a SkyRocket stuff in 6 months
Ready to make a product?

4. “Life is what happens when you’re
busy planning other plans”

5. So after approximately 6 weeks
• You regret to have left your job to start a
company
• You hesitate at learning all programming
languages yourself: “I know it should be done
this way”
• Process tools have already changed twice
• One guy has left, so you hesitate to fire a
second one, because 3-2 = 1

6. Somewhere this is disturbing
• The more you talk to so called “experts”, the
more you are confused
• You know where you want to go, and what your
product should feel like.
• Simply you do not know which road to take,
where to start fix it, and you need more than an
anchor
• Time to step back

7. So let’s find our way
• Apprehend the technical complexity of a
product of today
• Tune your setup
• Consider the constituting blocks, and what
neuronal connections should be developed.

8. It’s so easy for your kids

9. Preamb: again, the following are based on my personal
feelings along this path. I do not pretend to write an history
book.
A little bit of history

10. Dawn of personal computing
Unix MacintoshZX81
Micro Computing: we write applications to manipulate data and
first of all to create documents (text, music, …) and move them
to an another support (CD, paper). Content is the output and we
forget Unix
1970 1981 1984

11. A networks comes in
Server comes back : we write content to present it and technology to search it.
Clients are strong but start to be seen as way to browse content, in addition to
create it. Age of “universal hope” : all Microsoft, all Java, all HTML
1993 1995 1998/91995
Mosaic Windows 95 Altavista Google

12. Free of my movements and friends
gmail iPhone
Mobile development is creating a stronger link client to server.
Browsing of document turns to service (API). Social media provides
influence of other. Cloud computing bring programmable computing
power. Document export is now barely an issue (press online players,
Streaming music)
2004 2008 2008
Facebook
2006
AWS creation

13. My data, my objects
2009 2010 2013
Big Data (Hadoop) Nest Founded Android market lead
Mobile becomes the number one priority. Technologies are created to
handle massive data processing, connected object appears. We have
gone so far from document creation. All this has become a full graph
and power consumption is a concern.

14. Complexity
Desktop computer
Mobile
Server
Connected objects

15. Complexity

16. Complexity

17. Complexity

18. Complexity

19. Paradox
• The more complex it is, the easier it looks. Think
about how works a human body. Marvelous
machine still not imitated
• In vast complex system, each small components
brings its own world and complexity. A little bit
like “all cells contains the DNA”
• A saying goes that the problems solvable by
kids are the most complex one in computer
science
Do not mix the small complexity versus the bigger vision one

20. Additionnally
• Natural movement: when one has understood
something, it becomes a reference. But the
more you deal with technology, the less you
believe in one, and the more you think about the
usefulness of all. Techno of today fades out
tomorrow
• Creativity brings creativity. Why do some people
still look for the universal programming language
or method or whatever, when the global system
is about individuality. Paradox with the natural
movement.

21. Additionnally (2)
• The more you advance in development the more
the simplicity of your product will translate into
the proper use of complex technology
• Said differently : trying to force a complex
system to fit into one simple view is like putting a
circle in a square shape (of the same surface)
If you believe there is one “easy” solution you’re
doomed ,After a while it is as much a question of feeling
than knowledge

22. Set up

23. Cards in hand
Humans
Tools
Means
Process

24. Cards in hand
• Humans are your team. You should enthusiast
them every day, while driving strongly into one
direction
• Means are all the technologies available. There
are so many and understanding one is already a
complex thing
• Tools are here to help you accomplish your
goal. But they also require a learning curve and
will do nothing by themselves
Process will transform all those elements in a fluid system

26. Humans

27. The CTO
• A respectable CTO should be a at first a
choreographer
• A respectable CTO should still code with what he
doesn’t know and knows how to debug.
• A respectable CTO should always have the question
in my mind : “If I was really coming to this team today,
how much time would it take for me to get in, and what
would I understand in regards to the target goal”
Do not believe a CTO is only someone with “more technical
knowledge”

28. The team
• As a macro system/ as a micro system
• Macro should always prevail for a product
development.Enforcing this will prevent
individualism. This is management job
• Each ones brings competence and a Dreyfus level
model to the macro system.
• Creating a grammar for the product in your team is
essential
In the end, written form will prevail. The one who believes
that it is evident because it looks like will lose.

29. Process- Engineering Project
Manager
• EPM is a concept I met in a big company.
• Job description is “remove the road blocks”
• Takes note, nag people, manage the bug stack,
do report. This is a no-bullshit role.
• Think about him/her as a second right hand
The only process that will work is the one that you work hard
enough to transform into an habit. Someone needs to work
harder

30. Common pitfalls
• Complexity is always done in the name of simplicity.
• After development freedom comes too much
process
• “Do it now” works better in 75% of the cases.
Otherwise write a bug
• Why are people so afraid to throw away things in
the name of “in case of”. Throw them
• Avoid arguing, enforce rules
• A so called expert is having only his own brain

31. The advancing guitarist
By Mick Goodrick
“The best guitar book ever written””
Apply to software development

32. The advancing guitarist for product
development
• Explore the power of limitations
• Don’t be too fast: spend time on all what you can
get from a detail
• If you enter competition keep it for you. Works
fine within your team. Being alone when you
work, is the case in 90% of the situations
• Nothing is ever done. This is not the case in
guitar learning, why would you believe it in
Software development

33. Means

34. • The vast fields of available technologies
• Stuff of today will be partially obsolete tomorrow.
Whatever people pretends. Still fundamentals
stay. Each generation makes a problem
important
• Choice is always a problem. Take the one that
corresponds to your company need : recruiting,
time to market, cost
Means

35. Can I develop faster with this one?
As a pure personal opinion, and based on my experience, I
consider no technologies brings faster development in
absolute

36. But…
• If you get class A developers, it will go faster
• Some technology will be faster to reach an
intermediate state (e.g do I need a prototype)
• Some technologies will get an ecosystem
momentum.
• There are always cases where a technology will
fit your constraints (e.g databases)
• You may choose a technology for a part of the
way and switch to another. Be contextual.

37. Tools

38. Rule of thumb
• The only good tool is the one you will adopt. No
other. You often read “The tool does this”. This is
not true: you do this
• You need basically
Bug system
Build/Distribution
System
Report & Test
System

39. Bug system
Some example I did cross (Radar is missing :-()
It has to become the center point. This is the rule to
enforce “write a bug”. Defer the philosophical
discussion on “is it a bug or a feature”
Anyway…it’s a clever todo list…

40. Build and Deployment system
• Make software available as soon as it is done.
Everyone has the right to some regression
• Goes with creating different environments: prod, dev.
• Ensure the fact that “anyone” can deploy. If mistakes
are made this will be a good lesson
• May be painful on mobile (provisioning profiles…)
• Goes also with a source version control system and
with versioning
Better more versions, even not finished, than too less

41. Test and report system
• Testing has a value only if you test something that you
believe will not happen
• Testing comes through usage. It is understanding how
things should work
• Automate tests before a big operation : warning this is
time consuming
• Reporting is way to link to the user: you may need to
create it yourself

42. Example: mobile client reporting
• Create a log system : defines event class ,
format, storage mechanism.
• First have user send it manually through email
• Format the email nicely
• Make sure it can be activated remotely
• Make an API to report it
• Have it work when no user is registered
Each step will help you understand what you track

43. From the start report

44. So what?
• The tool created here provides a common reference,
a common vocabulary and talks to everyone
• It is a preamble to real user situation and so is not an
“internal use tool only”
• It makes the team ask questions about what happens
really in regards to what is supposed to happen
• It get cold facts
Digging into test and usage is about being drastically
honest

45. Some Technical verbiage

46. Goal of this part
• Provides beacon, push all questions around one
topic
• Give some familiar technology names
• Certainly not be exhaustive

47. Elements in the complexity
Infrastructure
Server
Mobile Desktop

48. Elements in the complexity
API
Language
Misc
Storage

49. Infrastructure

50. • The power engine of your system: compute,
storage, network
• You’ve heard about cloud: infrastructure
becomes programmable and instantly
configurable: one more element gets the
complexity DNA
• Main Providers
What are we talking about?

51. Many other players around
Answer to particular need, with different level of abstractions
and easiness of manipulations. Complete ecosystem around

52. • Your system will have to be accessed, back-up,
monitored, restored (in emergency), started and stopped
potentially by many developers, secured, code deployed
• Contrary to the belief that it makes infrastructure easier,
after a while cloud forces you to understand many
concepts of networking
• With great power comes great responsibilities (this is a
personal advertisement for Nephorider)
• The eternal question : it does not work the same on my
local machine : Docker!
Implications

53. Languages

55. The short/no discussion version
• There is assembly
• There is C
• There is Lisp
• OK… maybe Java

56. Maybe it requires more: explore this
• Procedural, Object-oriented, functional
• Compiled, just in time compilation, interpreted
• Statically typed, dynamically typed
• On the client, on the server
A language provides a way to think about a problem

57. Servers

58. What server are we talking about?
• Web server versus application server
• Web server deals with the requests
• Application servers do the work
• Between them there is something called CGI
(roughly).”I pass the work to my neighbor”. When it
fails find which one.

59. Web servers
• The first in line: needs to be fast
• Multiple server for fixed constants and fast answer:
CDN
• Handle protocol. Remember 80 (non secure) and
443 (non secure) : verify you talk to the right guy,
speak in coded language. Read hackers book

60. Application servers
• May or not work in a CGI like setup (PHP)
• They bring a methodology to develop application (MVC)
• They link endpoints request to objects, concepts and
storage

61. API

62. Scope of word: application programming
interface
• Exposes a nice learnable and usable model with
a set of functions of methods of the concept of
your product
• Apply also to the libraries and frameworks you
are using
• Not an HTTP only concern of course!!!
• Should never exposes how it is implemented

63. Some principles
• Make sure it is learnable easily if you want it to
be adopted
• Make sure it is 200% coherent
• Use the HTTP vocabulary available, read about
REST concepts
• Make it auto describing : no ambiguity when
reading…or parsing. Uniquely identify each
entity

64. Words you may bumped into
• Slices (things little by
little), fields (get only
partial elements in
answer)
• JSON means nothing
• XML neither…

65. Storage

66. Storage for what?
• Organize and keep data “that has a meaning”
• Stored data has another form than live one. It
may requires extra data to access it fast
• Always question of compromises : how much
size to store it, how fast can you access it, how
fast can you write it
• Growth of the system is important (sharding)

67. Databases, databases
• At first we all wanted to think structurally
• SQL is a programming language designed for
managing data held in a non relational database
manegement system.
• We can say this is talking about a model

68. The NoSQL movement
• Different types all addressing a particular
problem in the SQL world or dealing with
particular type of data, in some memory
configuration
• Do not use it only to “do NOSQL”. When you use
it , adopt the mindset
Document Graph
Key-Value Column based
(Big data oriented)

69. Desktop

70. One of the most famous technology trio

71. Looks so easy it becomes incredibly
complex and powerful
• Originally Document based
• Separation of content and display
• Document became programmable and turned
into applications
• Integrate in an ecosystem : tags are element of
a semantic puzzle (e.g SEO)

72. Evolutions
• Full feature frameworks (AngularJS, EmberJS…)
provides methodology to develop application
• Graphics become more elaborate (e.g SVG)
• Handle different output device (e.g Bootstrap)
this is what is called “responsive”
Strangely enough I find it has less profusion of “new”
technologies…but this is very personal

73. Mobile (native)

74. Lanscape

75. Send back to the past
• Back to some “forgotten” problems
• Power consumption, network quality, speed of
execution
• But way more demanding as “output level” :
usability, animation…

76. Communication device
• Not only as phone
• But as a set of sensors for me (e.g GPS…)
• 2 paths communications: normal HTTP,
Notifications in all ways (APN…)

77. Misc

78. • Search : use component (ElasticSearch) or
Service (Algolia)
• Social networks : gives at first a way to identify
yourself, but also access to a vast database of
data/users (OpenGraph)
• Measure your result : Analytics
A few more things to thing about

79. Thank You!