
Wellcome to our virtual walk from Ambleside to Howtown on Lake Ullswater. I’ve based the route on #HadriansHighWay by @fellranger1 which he uses a variant to the main route. Books can be bought direct or through @VindolandaTrust





More from Tech
A common misunderstanding about Agile and “Big Design Up Front”:
There’s nothing in the Agile Manifesto or Principles that states you should never have any idea what you’re trying to build.
You’re allowed to think about a desired outcome from the beginning.
It’s not Big Design Up Front if you do in-depth research to understand the user’s problem.
It’s not BDUF if you spend detailed time learning who needs this thing and why they need it.
It’s not BDUF if you help every team member know what success looks like.
Agile is about reducing risk.
It’s not Agile if you increase risk by starting your sprints with complete ignorance.
It’s not Agile if you don’t research.
Don’t make the mistake of shutting down critical understanding by labeling it Bg Design Up Front.
It would be a mistake to assume this research should only be done by designers and researchers.
Product management and developers also need to be out with the team, conducting the research.
Shared Understanding is the key objective
Big Design Up Front is a thing to avoid.
Defining all the functionality before coding is BDUF.
Drawing every screen and every pixel is BDUF.
Promising functionality (or delivery dates) to customers before development starts is BDUF.
These things shouldn’t happen in Agile.
There’s nothing in the Agile Manifesto or Principles that states you should never have any idea what you’re trying to build.
You’re allowed to think about a desired outcome from the beginning.
It’s not Big Design Up Front if you do in-depth research to understand the user’s problem.
It’s not BDUF if you spend detailed time learning who needs this thing and why they need it.
It’s not BDUF if you help every team member know what success looks like.
Agile is about reducing risk.
It’s not Agile if you increase risk by starting your sprints with complete ignorance.
It’s not Agile if you don’t research.
Don’t make the mistake of shutting down critical understanding by labeling it Bg Design Up Front.
It would be a mistake to assume this research should only be done by designers and researchers.
Product management and developers also need to be out with the team, conducting the research.
Shared Understanding is the key objective
I\u2019d recommend that the devs participate directly in the research.
— Jared Spool (@jmspool) November 18, 2018
If the devs go into the first sprint with a thorough understanding of the user\u2019s problems, they are far more likely to solve it well.
Big Design Up Front is a thing to avoid.
Defining all the functionality before coding is BDUF.
Drawing every screen and every pixel is BDUF.
Promising functionality (or delivery dates) to customers before development starts is BDUF.
These things shouldn’t happen in Agile.
A brief analysis and comparison of the CSS for Twitter's PWA vs Twitter's legacy desktop website. The difference is dramatic and I'll touch on some reasons why.
Legacy site *downloads* ~630 KB CSS per theme and writing direction.
6,769 rules
9,252 selectors
16.7k declarations
3,370 unique declarations
44 media queries
36 unique colors
50 unique background colors
46 unique font sizes
39 unique z-indices
https://t.co/qyl4Bt1i5x
PWA *incrementally generates* ~30 KB CSS that handles all themes and writing directions.
735 rules
740 selectors
757 declarations
730 unique declarations
0 media queries
11 unique colors
32 unique background colors
15 unique font sizes
7 unique z-indices
https://t.co/w7oNG5KUkJ
The legacy site's CSS is what happens when hundreds of people directly write CSS over many years. Specificity wars, redundancy, a house of cards that can't be fixed. The result is extremely inefficient and error-prone styling that punishes users and developers.
The PWA's CSS is generated on-demand by a JS framework that manages styles and outputs "atomic CSS". The framework can enforce strict constraints and perform optimisations, which is why the CSS is so much smaller and safer. Style conflicts and unbounded CSS growth are avoided.
Legacy site *downloads* ~630 KB CSS per theme and writing direction.
6,769 rules
9,252 selectors
16.7k declarations
3,370 unique declarations
44 media queries
36 unique colors
50 unique background colors
46 unique font sizes
39 unique z-indices
https://t.co/qyl4Bt1i5x

PWA *incrementally generates* ~30 KB CSS that handles all themes and writing directions.
735 rules
740 selectors
757 declarations
730 unique declarations
0 media queries
11 unique colors
32 unique background colors
15 unique font sizes
7 unique z-indices
https://t.co/w7oNG5KUkJ

The legacy site's CSS is what happens when hundreds of people directly write CSS over many years. Specificity wars, redundancy, a house of cards that can't be fixed. The result is extremely inefficient and error-prone styling that punishes users and developers.
The PWA's CSS is generated on-demand by a JS framework that manages styles and outputs "atomic CSS". The framework can enforce strict constraints and perform optimisations, which is why the CSS is so much smaller and safer. Style conflicts and unbounded CSS growth are avoided.