7. I do not endorse any of the products or
brands mentioned in this talk.
I have used them, I am using them or I am
looking into using them in the near future.
8. This is an opinionated talk.
Some swearing may be featured in it.
***!
10. Humans build stuff as badly as possible,
but not worse.
Me Some call it “optimization”.
It is an strategy that works pretty well… until it doesn’t.
When it doesn’t it is usually because we crossed the crap line.
An expert is someone that has failed many times. That helps to
estimate the crap line in projects.
11. Advice
Based on my experience
and preferences. You may
disagree violently...
13. We are in the business of selling.
There is no other business.
The sooner you get it the better.
14. Do not sell your time!
Sell the product of your work,
not your time.
FYI: this is bad stuff.
Bodyshopping is a form of
modern slavery based on
“employment” ideas of the
18th Century.
15. Small is good.
It is the right thing to do.
Less people = less bullshit, less noise, more clarity.
Cut down the middleman between you and the final client.
Small clients are good for this strategy.
Everyone has his personal agenda, with personal objectives.
Personal agendas interfere with project objectives. Do the math..
16. Luke: Is the dark side stronger?
Yoda: No, no, no. Quicker, easier, more
seductive.
AKA: big corporation teams.
17. Broken telephone effect:
CEO > Marketing > Designer > B. Analyst >
Designer > P. Owner > T. Lead > Developer
Littered with middle
managers as well.
18. Fear is the path to the dark side...
fear leads to anger…
anger leads to hate…
hate leads to suffering.
Yoda
Fear of losing their jobs.
Large companies policies make people to
worry about their jobs, not their work.
19. This industry is cheap.
Code is cheap.
And this is one of the main problems with it. Everyone thinks
that we can keep making changes to code indefinitely because it
has a perceived cost of almost nothing; after all it is
“digital/virtual” and we can rewrite it at no cost…
20. Agile?
Whatever works for you!
For me it is a combination of frozen specifications, architecture
planned in advance (you need overall vision of the project),
prototyping, many checklists and agile Ganttified sprints.
But never “agile planning”, whatever that means.
21. Never start everything at the same time!
Big teams go large here.
I have seen things… whole development teams coding frantically,
directed by the PM, before the architect joins the project.
Someone hired them early and they must work (write code!) as
they are being paid to warm up their chairs.
The train can not stop: timber!
22. First, solve the problem.
Then, write the code.
John Johnson
Practical tip: print this slide and
paste it to your computer screen.
23. But we cost more and take longer than
building a house!
The average time to build a family house is 6 months.
The perception of cheapnes is the origin of our trouble as it provokes multiple
cycles of changes (together with developers reinventing the wheel in each
project). We do not have the restrictions of the physical world: when something
is done it cannot be changed. That helps the house builders.
24. Plain bad planning
It is really difficult to manage and plan projects.
Sometimes I have the impression that…
Those who can, code. Those who can’t, manage.
And that is not a good strategy for success.
A good PM is priceless.
And very rare.
25. Plans are of little importance,
but planning is essential.
Winston Churchill
Do not mistake software planning with project delivery planning.
The first one must be done in advance while the former may be
done in an agile way as the project progresses. I am afraid all
planning is treated in the same fashion by the agile crowds.
Mainly software planning
26. No battle plan survives
contact with the enemy.
Helmuth von Moltke the Elder
Always have a plan B.
27. Use checklists.
For absolutely everything.
The whole aerospace industry is based
around checklists. I am sure we can do
very well with them in our industry...
28. Use Gantt charts.
To control the work allocated to tasks and
the dependencies between them.
I am open for suggestions. And not, I do not trust
developers, or other people for the matter.
29. Development, design and content creation
work planned for one sprint. You only need
colourful post its and a large enough window.
31. Parkinson’s bicycle shed effect
Everyone knows better… the simple stuff. And our industry is
perceived as simple (we have been promoting it like that for over
a decade). The larger the team or group of people involved the
more difficult to control. And subordinates will not question their
masters… we are doomed!
33. Pareto principle (80-20)
80% of effects come from 20% of the causes
20% of code has 80% of errors
20% of features provide 80% of functionality
...
20% of staff create 80% of problems
For many events
approximately...
35. Metcalfe's law
The cost of interrelated or connected operations increases
exponentially with the number of connections:
- Testing becomes more expensive as the software grows and
relations increase between components.
- Team management gets more complicated fast with the number
of members (meetings, communications between parties, etc).
37. Parkinson’s law
Work expands so as to fill the time available for its completion.
So if a developer “thinks” that he has a sprint worth of time it will
take him one sprint to deliver. But if he thinks he has three days…
You need a Gantt chart to figure this out.
40. You need testing.
Automated testing.
Choose your flavour and tool and master them (TDD, BDD, PHPUnit,
SimpleTests, Selenium, etc). Get used to coding tests as you code
features (or before, up to you). Tests are your QA metric, your
benchmark for improvements, your professional standard seal. And,
for God's sake, test patches and bug fixes. Identify your smoke
tests and keep them updated.
41. The only valid QA measurements are
maintainability and reliability.
No one will care about feature x
if the application or site keeps crashing.
And no one will miss feature x
if the application runs smoothly and costs peanuts to maintain.
42. The central enemy of reliability is complexity.
Geer et al.
Get the idea. It is easier to say than to do.
43. Simplicity is prerequisite for reliability.
Edsger W. Dijkstra
Another way to say it.
It is important, so let's repeat it.
44. Bultaco Sherpa. My father’s motorbike.
Simple, robust, reliable, maintainable. Indestructible.
From 1970 to date (46 years in the family!). https://ca.wikipedia.org/wiki/Bultaco_Sherpa_T
45. Always code as if the guy who ends up
maintaining your code will be a violent
psychopath who knows where you live.
Rick Osborne
In case you didn’t get it.
46. Cost of (unit) testing?
Just a practical trick to
estimate the testing routines
required for your code.
47. N-Path complexity.
Number of unique paths in a routine.
Minimum number of tests required to completely
test a routine.
Got it? Me neither.
50. You do not need CI.
In essence it is a bunch of scripts
executed automatically on code
commits. You can do it manually on
demand and still be cool.
51. You do not need the cloud.
Local is good (if you can share it).
See DrupalVM later.
But backup your stuff!
52. Good and now is better that
perfect and tomorrow.
In code, testing and love.
Tomorrow never comes.
53. Share your work with other professionals.
We can’t do everything under the sun. Outsource work to professionals:
development work or supporting tasks (accountancy, contracts, etc).
Specialization leads to efficiency. Efficiency leads to profits.
54. If you think it's expensive to hire a
professional to do the job, wait until you
hire an amateur.
Red Adair Whatever you outsource will
affect your delivery with
your client. Find good
collaborators and be fair.
No client is worth few
pennies saved.
55. Prototype in Drupal.
Turn web building process around.
Start with Drupal, then Design and finish
with Drupal.
I have been championing
this for over 7 years.
I am not alone. At last!
See following slides
58. Understand the basics
Example: do not misunderstand technical debt with writing bad code
knowingly. Code must be always written as best as we can, with the
best understanding of the project at the point. Debt comes from
partial understanding of what you are coding (the project).
62. Sell!Do as little development as possible and as much selling as bearable.
63. Find your unfair advantage.
WHat do you do well? What is it that you do much much better than
others? Transform it in an advantage. Find a way of using it to
surpass your competitors, to stand out.
The more unfair (for others) the better (for you).
Go and find it!
64. Every client thinks he is an unique unicorn.
And no one is.
No one.
As small guys we are in a great position to manage their delusional dreams. We
are their experts, so behave as such and guide the client through a doable
plan to succeed. We control the product here. Avoid development spirals.
In big projects with big teams there are too many delusional unicorns to tame.
Not even you, I am afraid.
Be pragmatic here.
65. Manage expectations.
Communication is key.
Better to say anything early than late.
Bad news delivered frequently and with plenty of time are much much
better than saved until the very last minute. Most people are quite
reasonable if given time to react and respond. Don’t be afraid of
delivering bad news. Shit happens. The sooner we find out the better
we are positioned to fix it.
66. Time to market beats features hands down
Now and flawed is much better than never and perfect.
Cut down marginal-benefit features ruthlessly. And ship early.
Focus on the 20% that will give you the 80ish%.
67. Build a streamlined product and sell it
again and again. That is the key to profit.
Companies profit on top of imperfect
products.
The whole planet is doing it.
Why don’t we do it in “digital” industries?
Why can’t we?
68. Ditch your marketing department
Marketing is for when the clients find you. It is lazy selling. It
promises everything at the expense of development costs.
What small guys need is a hardcore salesperson to sell your “product”
to as many clients as possible. They need to be convinced rather than
promised any fancy dreams. Think of profitable actions here..
69. Lie about your professional standards.
Do not let the client to dictate them.
This is the only industry where the client decides about the
professional standards of the suppliers.
If the client or manager knows you will spend time testing your code,
he will try to remove it from the project. Testing is part of your
professional standards and responsibility. They can not be removed.
This is insane, madness!
72. Know your tools well.
The tools you use do not matter. What matters is how good you are
with them. So… use the web server that you know well!
Consider the cost of continuously adopting the “latest buzz thing”:
learning curve, slow development, inefficient development, technical debt,
short shelf life of new rapidly changing technologies.
73. The technology you use doesn’t matter as much as what you can do with it.
Stop running after the best new thing.
https://www.digitalocean.com/community/tutorials/apache-vs-nginx-practical-considerations
114. D6
D7
D8
B1
Drupal size Each “dot” represents a “book of code” of
760 pages, with 72 lines of code per page.
I totally dominate this!
24 volumes of code of 760 pages each! WTF?
How many developers do I need in my team to master it?
115. Drupal size
D 6.37 D 7.42 B 1.3.2 D 8.0.3
Files 500 1,100 2,100 12,300
Folders 60 150 330 3,600
Lines 55,000 177,000 230,000 1,300,000
Pages 760 2,500 3,200 18,000
Volumes 1 3 4 24
Calculated using cloc and tree and rounding the numbers for
clarity. Each page has 72 lines of code.
Drupal 8 includes vendor folder.
988,000 w/o vendor
116. https://backdropcms.org/ The moral is to pick the right tool for your size.
I would rather use Backdrop
than Wordpress…
don’t quote me on this.
