Trends In Application Development

In collaboration with
Trends in Application Development
Jens Riboe
September 2009

Who is Jens Riboe?
Engagements at Informator
Erlang
Real-time programming in C++
Groovy and Grails
Cloud Computing
Förliteolikakunder

Problem

Increased complexity
More tasks
More users
More realisations
More ways to failure
A quarter of a century of software development
A techniciansperspective

The longer you wait, the more it costs
The cost of fixing bugs
It willnever be as cheap to fix the problem, as right now

Make it so simple that there are obviously no deficiencies
or
Make it so complicated that there are no obvious deficiencies
Sir Charles Antony Richard Hoare
Twoprinciples of system design

When an ordered state transforms into chaos
Complexity

When the number of information units needed for problem solving far exceeds the capacity of the human brain
Physiological definition of complexity

When you passed the capacity, your brains starts trashing like a PC with too unsufficient RAM
A trashing brain cannot make well-founded descions
Which creates the mental foundation for bugs
More bugs, demands more time, which gives less time for features
Towards the end of the project, all time is spent on fixing the new bugs introduced during the bug fix last week
The consequences of complexity

Too many cross-wise dependencies
Too many modules
Too many lines of code per class and method
A picture of complexity

Focus on delivery of results
Maintain development speed
Remove obstacles
Simplicity
Communication
Change is the only constant
Agile principles
Do more with less

Isolate the team
Allow them to concentrate on their task
Enforce meeting free days
Use a common task list
Assign one person to do the prioritazion
Work in fixed time boxes
Define a delivery at the end
Ditch ancient tools
If it gets in the way, throw it out
Remove obstacles

What have you done?
What are you planning to do?
What prevents you from doing what you planned?
Ask the three questions every day

Methodology

Story
A luxury car was left for a week in a rough area, nothing happened.
Then one of its windows was broken. After a day, all that was left of the car, was a smoking car wreck.
Conlusions
Fix problems immediately
Continuous sanitization
Prevent the impression of hopelessness
Hopelessness leads to less ambitious work, which leads to more bugs, which leads to irresponsibility, which creates more hopelessness
Tip
Email every production log stack-trace to the developers
Fix Broken Windows Applied sociology to computer science

Story
A ladder leading up to a bunch of bananas was placed in a cage of monkeys. When the monkeys climbed up, the cage was sprinkled with cold water. Nobody climbed up.
A new monkey was let into the cage, and discovered the bananas. When he tried climbing up, he was beating by the others.
Another monkey was let into the cage and was beaten up by all, including the new monkey
Conclusions
Don’t just repeat what other are telling you unless you understand why and agree. Perhaps the root cause doesn’t exist any longer.
Avoid Screaming Monkeys Applied sociology to computer science

Eliminate all information duplicates
This is the opposite of cut&paste programming, which in many cases is a major source of bugs
A modification of a single element should not affect unrelated elements and logically related elements should change in a predictable and uniformed way
From ”The Pragmatic Programmer” 1999
DRY – Don’t Repeat Yourself

Stepwise improvements of code quality using stepwise transformations of the source code
ExtractMethod, FactorOutBaseClass, MoveClass, ...
Software development resembles gardening
Allocate time and plan for refactoring
A common problem
Initial simple design for few features
More features requires more elborated design
Required time for refactoring is denied
Work-arounds creates hopelessness . . .
Refactoring

Ensure every class/module/subsystem is testable
Automate all tests
Forbid manual tests
Create test reports and coverage reports
Testability improves the code quality substantially
Common problems
Sufficient time is not allocated for non-trivial tests
Old tests that fail, after a code change are, disabled instead of fixed
Testability and Unit testing

Convention over Configuration
(aka Coding by convention)
Avoid XML Hell
UseCbCframework and tools
Maven, Grails and manymore
Common problems
"Wehavebeenusing make for a verylong time"
"Wealreadyhave a guy that takescare of that bunch of recursiveAnt scripts, nobodyunderstands"
Configuration by Convention

Ensure the system always is
Compilable
Buildable
Executable
Testable
How
Work in small increments and check-in frequently
Avoid branches
Check-in to the main trunk
Unless for very specific and time limited tasks
Continuous Integration
But, it works on my machine!

Deliver components, not source code!
Shift the focus from delivery of source code to delivery of tested and documented components
“Hide” the source code
View it as property of the responsible team
A component is a
boundary for the progress of complexity
unit of understandability
unit of testability
Component

Use a new Version Control System (VCS)
No file locks and local state management
Attach a Web Front-end to the VCS
Source code must be browsable and linkable
Use a powerful IDE
The VCS must not block refactoring
Use a Wiki for static info
Editable for everyone on the team
Use a Blog for dynamic info
Capture the project history as it evolves
Use Configuration by Convention tools
Use a Continuous Integration server
Provide public access to the task list
Burn downchart
Use contemporary project tools

Technology

Shorter time to result
Expressive and compact code
Dynamictyping, ”ducktyping”
Groovy, Ruby, Python, Erlang and manymore
New languagesincreasesproductivity
def persons = Person.list().findAll{it.location}
def json='[' + persons.collect( {it as JSON} ).join(',') + ']'
[
{name:”jens”, email=“jr@foobar.com”},
{name:”wille”,email=“ws@foobar.com”},
{name:”anna”, email=“ac@foobar.com”}
]

The current trend of software development
Will affect the way working in the same manner as object-orientationdid 15-20 yearsago
New concepts
Closures
Continuations
Futures
Currying
Affectsevenoldlanguagessuch as C++
The new standard library C++0x
In the past STL, JGL
Pragmatic functional programming

Will affecthowwe design and deploy new applications
Amazon
ElasticCompute Cloud (EC2)
Elastic Block Storage (EBS) and Simple Storage Service (S3)
Simple Queue Service (SQS) and Simple DB (SDB)
Cloud Computing
From 50 to 3500 servers within a week
18 months
http://www.slideshare.net/startpad/startpad-countdown-8-amazon-web-services-and-you-470919/32
http://www.slideshare.net/startpad/startpad-countdown-8-amazon-web-services-and-you-470919/36
28

Easy and cheap to launchone or more servers
Project server
Test server
Load generator
. . .
$0.10 / hour
29

Apache Hadoop
DistributedMapReduce
DistributedFile Systems (HDFS)
Cheap to run 100-1000 nodes, for a limited time period
Large data computations
30

Load testing

Component Service Providers
Ready to use services for specific tasks
http://api.clickatell.com/http/sendmsg? to=46730314040&text=Hello+from+Jens
&user=uid&password=pws&api_id=aid
32

People

Team Revenue
R
=
+
+
+

Revenue of a single consultant
Max Revenue
Utilization0 ≤ u ≤ 1

Emperical observation 1
Utilization (μ) is an approximateconstant

The longer time a person is staying on the same project, the closer his/her revenue is to the market average

The moreconsultants in a project, the closertheirrevenue are to the market average

Revenue of a single consultant
Market Average
Hourly Rate
Competencecoefficient0 ≤ k

The Consultancy Equation
Number of
consultants
MeanCompetence
MeanUtilization

The law of gravity for the consultancy life
Salary plus Cost must be less than Revenue.
However, Revenue is a linear function of the number of delivery units (consultants).
Salary
CostContribution

Affecting forces
Seller
Perception of competencelevel
Type of engagement
Purchaseprinciples
Standardization
Buyer

Consultancy Buyer
Off-shoring
Consultancy Seller
Junior-shoring
Consultant
Job-hopper
Career switch
Compensational strategies
The economic rules are the same in Stockholm and Bangalore

Forces

The food chain of the consultancy market
Deliver Results
Trend
Price / Hour
Deliver Hours

Effective Business Model
Sell more hours
Create more bugs so we can stay longer
Sell more projects
Work smarter and faster so we can stay shorter

The impact of competence development
Minor
Major

The collectiveknowledge of a projectconsists of
Formal (written) documentation
Source code
Design documents
Informal (”invisible”) documentation
Project specifics
Developerpractices
Language and platformidiosyncrasies
A new person need to acquireboth kinds of knowledge
What you cannot read, you have to ask for och knowalready
For a non-trivial project it mighttake 6-12 months to reach full productivity
Depends on skilllevel
CollectiveKnowledge of a Project

Collectiveprojectknowledge
Formal docs
Informal/invisibleknowledge
Needboth to be productive and contribute
The time required for knowledge transfer is dependent on
The amount of invisibleknowledge and the skilllevel
For a non-trivial project it mighttake 6-12 months to reach full productivity
Knowledge transfer steals time from develoment
The compensationalstrategiescauses
A stream of new persons (mostly at a junior skilllevel)
Continousdemand of knowledge transfer
Knowledge and Productivity
knowledge
time
Draining
Contributing

If the staffturnover rate is too high, the contributing period becomestooshort
If the non-contributing (draining) period takes a significant portion of the project time, the project is graduallyloosingitscollective ”invisible” knowledge
At the end, ”nobody has a clue”
The knowledge transfer dilemma
Accumulated (invisible) knowledge
Time

Conclusions

Not a singlesource of fault, however
Organizational habits tends to go in the way and preventdeveloperproductivity and project evolution speed
Systemic Problem

Methodologies, Languages and Tools
More bang for the bucks gained
Higher abstraction level required
Higher involvement required
Higher competence level required
Organizations
More bang for the bucks gained
Standardization and policies required
Lower involvement required
Ignorance of competence level required
Opposing ambitions

A small high competent team outperforms a large low competent team, many times
Code and application quality
Development time and time top market
Total cost is lower
Organizational obstacles
Salary and/or hourly rate level matters
Policies and procedures matters
The head count matters
The total cost is larger
Less is More

Flip directions
Technology
New languages and tools, at a higher abstraction/competence level
Methodology
New way of working, at a higher abstraction/competence level
Team size smaller
Software developement
High quality and low cost
Flop directions
Hourly rate and business models
Policies and procedures
Team size larger
Software developement
Low quality and high cost
Summary

Questions?

Jens Riboe
+46 (0)730-314040
jens.riboe@ribomation.com
www.ribomation.com
blog.ribomation.com

http://blog.ribomation.com	120
http://www.google.se	1
http://www.slideshare.net	1

Trends In Application Development

by Ribomation on Sep 12, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 122

Statistics

Trends In Application Development — Presentation Transcript