Mais conteúdo relacionado
Semelhante a Another Copernican Revolution: maintenance first, projects second (European Drupal Days 2015) (20)
Mais de Eugenio Minardi (19)
Another Copernican Revolution: maintenance first, projects second (European Drupal Days 2015)
- 1. © Ibuildings 2014/2015 - All rights reserved
#DrupalDaysEU
(We Need) Another Copernican Revolution
– or –
Why Maintenance Doesn't Suck
but Big Projects Do
- 4. © Ibuildings 2014/2015 - All rights reserved
Speaker Info
Christopher Torgalson
Drupal Developer
christopher@torgalson.net
@bedlamhotel
Chromatic!
- 5. © Ibuildings 2014/2015 - All rights reserved
The Copernican Revolution
(An Allegory In Pictures)
●
The Copernican Revolution is
notable because it completely
inverted how people thought about
celestial motion
- 6. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
PTOLEMY: GEOCENTRIC!
http://bit.ly/1F0BIw1
●
The geocentric, Ptolemaic model
made it dicult to account for the
motions of celestial bodies.
●
But it had the huge advantage of
being incredibly obvious
●
The sun clearly moves around the
earth
●
But...
- 8. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
HELIOCENTRIC!
(And everybody lived happily ever after)
http://bit.ly/1MJPN0b
●
The heliocentric model wasn't as
blindingly obvious
●
But it made it made a lot of things
(such as the fact that planets
appear to move backwards for part
of their orbits) much easier to
explain
- 9. © Ibuildings 2014/2015 - All rights reserved
Sometimes, our thinking about making websites is a little
PTOLEMAIC
●
Some of the things we do are
inside-out, or backwards, or old-
fashioned
●
I'd like to see a Copernican
revolution in our industry
●
Not every project or organization
su+ers severely from these
problems, but the organizations
and sites I've worked on have
almost all had a degree of
“Ptolemaic” thinking
●
But .rst, some background...
- 10. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
All websites have problems.
https://www.flickr.com/photos/wordollhouses/2775311134
●
This is true whether we build or
inherit the websites
- 11. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
These problems tend to get worse over time
https://www.flickr.com/photos/usachicago/4720385881
●
Code—and sometimes even UIs—
become harder to work with
●
CI deteriorates
●
Quality, in general, degrades
- 12. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
We refer to these problems collectively as...
(TL;DR: EVERYTHING WE SCREWED UP AND DIDN'T FIX)
●
All projects have some
●
All projects are at risk for more
●
There are multiple causes some of
which are systemic
●
I don't have a solution to the
problem, but I have a diagnosis of
one of the systemic ways it can
come about
- 13. © Ibuildings 2014/2015 - All rights reserved
When it comes to building websites, what do we
PRIORITIZE?
●
Very often, it's big projects at the
expense of maintenance
- 14. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
BIG PROJECTS!
https://www.flickr.com/photos/zoriah/5888742159/
●
We prioritize big projects
●
They tend to monopolize resources
and devour large budgets
●
But, they involve full teams on
both the client and agency sides
●
And, they accomplish a lot
●
But...
- 15. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
NOT MAINTENANCE!
https://www.flickr.com/photos/metrolibraryarchive/11225561005
●
Maintenance is often neglected
●
It usually does not involve either
the full client or agency team
●
It often neglects process
●
Timelines may be short/budgets
small
●
Sometimes decisions are left to
engineers and overall strategy gets
neglected
●
Sometimes decisions are left to
clients, and best practices are
neglected
●
Often little is accomplished
- 16. © Ibuildings 2014/2015 - All rights reserved
There's Maintenance and there's
“MAINTENANCE”
●
At least now we do maintenance in
the .rst place
●
But even when we do, the results
are variable
- 17. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
BAD MAINTENANCE
• Problems in custom code go unfixed
• New problems regularly introduced
• No consideration of coming upgrades
• Code quality deteriorates
• Ad-hoc solutions proliferate
• Compliance with CI decreases
• TECHNICAL DEBT INCREASES
https://www.flickr.com/photos/cmdrcord/9414641873
●
Bad maintenance comes in several
varieties:
●
No maintenance
●
The “Apathy” model
●
New features only
●
The “Magpie” model
●
Security upgrades only
●
The “Better Than Nothing”
model
●
Core and module upgrades only
●
The “Status Quo” model
●
Less bad, but what about all
that custom code we wrote?
- 18. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
GOOD MAINTENANCE
• Fixes bugs
• Adds / improves documentation
• Eliminates ad-hoc solutions
• Uncouples (too) tightly-coupled systems
• Favours stable APIs over custom code
• Reduces (unnecessary) complexity
• TECHNICAL DEBT DECREASES
• But is it worth the EXPENSE?
https://www.flickr.com/photos/orkomedix/7297075780
●
Prevents new technical debt by
involving client and agency teams:
●
best practices respected
●
Strategy considered
●
It is planned, speci.ed, scheduled,
and it should have speci.c,
measurable goals
- 19. © Ibuildings 2014/2015 - All rights reserved
We need to take care of our codebases because they
WON'T GO AWAY
●
In fact, they are living longer and
longer
●
We are heading for a time when
individual components can live
inde.nitely
- 20. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
Upgrades are becoming less terrible
• Semantic versioning
• Symfony
• Twig
• SASS
• Front end
• Headless
• Migrate API
●
The whole Drupal ecosystem is
heading in a direction that will
make upgrades easier
●
interoperability
●
looser coupling between the
Drupal backend and frontend
●
Semantic versioning promises to
make this easier too (at least
within versions)
●
More custom code will survive
upgrades
- 21. © Ibuildings 2014/2015 - All rights reserved
So what's this
REVOLUTION?
●
All I propose is that we focus on
sites' lifetimes rather than their
birthdays
●
Maintenance happens far more
often and for far longer than the
initial project
- 22. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
SHRINK BIG PROJECTS
https://www.flickr.com/photos/sanctusguy65/400145232
●
Simply put, don't throw everything
that's ever going into the site at
the outset
●
Plan to roll out core functionality,
followed by staged release of
features
- 23. #DrupalDaysEU
© Ibuildings 2014/2015 - All rights reserved
PRIORITIZE MAINTENANCE
https://www.flickr.com/photos/roystan/3763647394
●
Would it help if I called it Iterative
development?
●
Use agency teams like sta+
●
Look to SAAS as a model
●
Deprioritize large projects
●
Allocate more resources to
maintenance
●
Where possible decompose large
projects into many smaller projects
●
Sometimes we must build large
projects in one go—but make sure
that we must
- 24. © Ibuildings 2014/2015 - All rights reserved
Educate
CLIENTS
●
Get the word out to whoever it is
you build sites for
●
Code is the vehicle used to
accomplish their communications
objectives
●
Speed, convenience, missing
features
- 25. © Ibuildings 2014/2015 - All rights reserved
Educate
COLLEAGUES
●
Poor, hastily-developed,
incomplete, or broken code:
●
Makes new development/coding
take longer