I have not found an automated way to generate a nice PDF from some slides written in HTML – if you know of one please add a comment!
In the meantime, if you create slides using my HTML Slides template, then you can make a decent-ish-looking PDF like this:
View your slides in Firefox and open the Print dialog (press Ctrl-p).
Select Print to File and choose a filename to save to.
Under Options deselect “Ignore Scaling…” and select “–blank–” for all the headers and footers. Ensure “Print Background Colours” and “Print Background Images” are selected.
Under Page Setup set Scale to 70.0 and Orientation to Landscape.
Select the dropdown next to Paper size and choose Manage Custom Sizes…
Create a new custom size called “Screen 16:9” with Width 157.5 mm and Height 280.0 mm. Set all the Paper Margins to 5.0 mm. You can modify the name of the custom size by clicking on it in the list on the left. Click Close.
Back in Page Setup, make sure your new custom size is selected next to Paper Size.
Click Print.
If that does not work well for you, try experimenting with different Scale settings.
The Software Freedom Conservancy helps Free/Open Source software projects by providing infrastructure, financial structures, and legal help. It is a not-for-profit organisation that is dedicated to software freedom, something that I think is an important prerequisite for a decent world in the future.
Conservancy looks after lots of projects, including these ones that I personally use: Boost, BusyBox, Etherpad, Git, Godot Engine, Inkscape, phpMyAdmin, QEMU, Racket, Samba, Selenium, Squeak and Wine.
It provides an easy way for projects to accept donations, hold assets and negotiate contracts, as well as mentoring and legal advice. It also leads the difficult and thankless work to persuade (and force) companies to comply with the GPL (a Free Software license). Without this work a great deal more Free Software would be distributed without the required access to source code, meaning it is not free at all.
Further, it is a key supporter of Outreachy, which does important work to address the under-representation, systemic bias, and discrimination in the technology industry.
A few years back I got to spend a couple of weeks consulting at a small company involved in the production of smart cards. My team had been brought in by the company’s management to cast our critical eye over their software development process and provide a report on what we found along with any recommendations on how it could be improved.
The company only had a few developers and while the hardware side of the business seemed to be running pretty smoothly the software side was seriously lacking. To give you some indication of how bad things used to be, they weren’t even using version control for their source code. Effectively when a new customer came on board they would find the most recent and relevant existing customer’s version (stored in a .zip file), copy their version of the system, and then start hacking out a new one just for the new customer.
As you can imagine in a set-up like this, if a bug is found it would need to be fixed in every version and therefore it only gets fixed if a customer noticed and reported it. This led to more divergence. Also as the software usually went in a kiosk the hardware and OS out in the wild was often ancient (Windows 2000 in some cases) [1].
When I say “how bad things used to be” this was some months before we started our investigation. The company had already brought in a previous consultant to do an “Agile Transformation” and they had recognised these issues and made a number of very sensible recommendations, like introducing version control, automated builds, unit testing, more collaboration with the business, etc.
However, we didn’t think they looked too hard at the way the team were actually working and only addressed the low hanging fruit by using whatever they found in their copy of The Agile Transformation Playbook™, e.g. Scrum. Naturally we weren’t there at the time but through the course of our conversations with the team it became apparent that a cookie-cutter approach had been prescribed despite it being (in our opinion) far too heavyweight for the handful of people in the team.
As the title of this post suggests, and the one choice I found particularly amusing, was the introduction of VSTS (Visual Studio Team Services; rebranded Azure DevOps) and a GitFlow style workflow for the development team. While I applaud the introduction of version control and isolated, repeatable builds to the company, this feels like another heavyweight choice. The fact that they were already using Visual Studio and writing their web service in C# probably means it’s not that surprising if you wanted to pick a Big Iron product.
The real kicker though was the choice of a GitFlow style workflow for the new product team where there were only two developers – one for the front-end and another for the back-end. They were using feature branches and pull requests despite the fact that they were the only people working in their codebase. While the company might have hired another developer at some point in the future they had no immediate plans to to grow the team to any significant size [2] so there would never be any merge conflicts to resolve in the short to medium term! Their project was a greenfield one to create a configurable product instead of the many one-offs to date, so they had no regressions to worry about at this point either – it was all about learning and building a prototype.
It’s entirely possible the previous consultant was working on different information to us but there was nothing in our conversations with the team or management that suggested they previously had different goals to what they were asking from us now. Sadly this is all too common an occurrence – a company hires an agile coach or consultant who may know how to handle the transformation from the business end [3] but they don’t really know the technical side. Adopting an agile mindset requires the XP technical practices too to be successful and so, unless the transformation team really knows its development onions, the practices are going to be rolled out and applied with a cargo cult mentality instead of being taught in a way that the team understands which practices are most pertinent to their situation and why.
In contrast, the plan we put forward was to strip out much of the fat and focus on making it easy to develop something which could be easily demo’d to the stakeholders for rapid feedback. We also proposed putting someone who was “more developer than scrum master” into the team for a short period so they could really grok the XP practices and see why they matter. (This was something I personally pushed quite hard for because I’ve seen how this has played out before when you’re not hands-on, see “The Importance of Leading by Example”.)
[1] Luckily these kiosks weren’t connected to a network; upgrades were a site visit with a USB stick.
[2] Sadly there were cultural reasons for this – a topic for another day.
[3] This is debatable but I’m trying to be generous here as my expertise is mostly on the technical side of the fence.
In March I’m going on tour, I’m speaking at Agile on the Beach New Zealand. I hope to call into Australia on the way, and I’ve been invited down to Wellington too.
My itinerary is not confirmed yet and ideally I’ll delivery some more talks – and charge some fees to make the trip more sensible. So if you know anyone in Australia or New Zealand who would like me to deliver some training or presentation please put them in touch, allan@allankelly.net.
Which makes it a great time to introduce my Fresh Ideas workshops.
These are short (2 to 3 hours) workshops which expand on ideas you will find in my conference presentations and books. So far these are:
Value and the story: this includes an estimation poker exercise which is a lot of fun
Continuous Digital: ideal for regular readers of this blog who want to share these ideas with their colleagues.
Agile refresher: this features in my agile training and has been run a number of times as a stand alone exercise, it is a lot of fun and a way to start a conversation about getting better
As always, if you are interested in any of these get in touch – especially if you are in New Zealand or Australia.
Hierarchy, it is one of those topics which provokes a reaction.
There are many in the agile community who believe hierarchy is a bad thing. Teams – and whole organizations are better off without hierarchy. It is simply(!) a case of finding better ways of organizing which don’t involve hierarchy.
Then there are those who acknowledge that hierarchy has been with us for millennia and find it hard to imagine how anyone could organise without it.
As a general rule the supporters of agile come down against hierarchy. I’ve been known to rail against hierarchy myself but at the same time I’ve long had my doubts that it is possible to remove hierarchy altogether. Rather I aim for less hierarchy and greater independence rather than the abolition of all hierarchy. I tend to keep this view to myself because a) it is subtle and b) I suspect I’ll loose a lot of agile street cred if people know.
So when I heard about a book called Hierarchy by John Child I immediately bought a copy. This is no easy read – Child is a Professor and so the style is academic rather than pop-psychology business blockbuster. So far I’m about half way through but the book raises many interested point that I’m still thinking through.
In particular Child highlights a number of benefits of hierarchy which deserve attention and I think are too often overlooked. Right now I want to capture my thoughts so far before I get into the arguments against hierarchy. So…
The benefits of hierarchy to an organization:
Hierarchy has benefits were there is regulation
Hierarchy helps large enterprises bring structure to their activities
Hierarchy tend to develop in all societies whether they are intended or not, therefore imposing a hierarchy gives an organization a chance both to impose the order they want – and choose the leaders – and rather than accepting the hierarchy and leaders that emerge.
Hierarchy allows for succession planning
Reduce illegal behaviour: maybe not a big issue in your twenty-first century office but this can be an issue. It can also be a particular issue when people rise to the top of a hierarchy and find the organizational controls they had before are gone: they have nobody to report to. Could this explain some of the sexual and business mis-conduct that has been in the media in recent times?
Benefits to the individual:
Hierarchy creates psychological safety, individuals know where they fit in and what is expected of them. They know who they need to pay attention to.
Hierarchy reduces cognitive load and fear, in part because of the psychological safety it creates.
Hierarchy provides a career model: people know what advancement in the organization looks like and those who want advancement can map out a course to achieve that.
Benefits to a team:
Hierarchy creates clear areas of responsibility which enables team members and creates focus within the team.
Hierarchy provides team members with a structures and helps them accept their position. On the whole people are accepting of hierarchy and accept the position. (Perhaps because they also know how they can advance their position.)
Hierarchy allows a mix of strong and weak personalities to work together. While hierarchy can be used by powerful formal leads to suppress weaker staff hierarchy cuts both ways. Team decision making can be improved when hierarchy facilities equitable discussion between strong personalities.
Formal hierarchy, with formal leaders, actually puts a responsibility on the leaders to ensure balance and allow weaker personalities to have their say. (While this can be abused when it is abused it should be clear to all concerned that the leader is not upholding their part of the bargain.)
In a recognised hierarchy the senior people have a responsibility to moderate and listen to all. Where there is no hierarchy few may feel that responsibility and a single strong voice may dominate the weak.
Where there is no hierarchy and multiple strong personalities the result can be conflict and disagreement. Without the hierarchy it can be hard to resolve such problems.
Hierarchy provides for decision makers, perhaps one, perhaps more. Having recognised decision makers can make for rapid decisions: people know who to go to and that person knows they have responsibility. Conversely, where decisions are made by consensus decision making can be slow or absent entirely.
Recently I observed a team which made most decisions by consensus. But as one strong personality rarely agreed with the others any decision they didn’t agree with became a battle field. Most team members kept quiet and nothing changed. Sometimes another strong personality would try and force the decision through but this was usually unsuccessful. Only when several other team members were prepared to take sides. As a result consensus became a recipe for not changing.
Of these arguments the ones I find most interesting are those which concern the emergence of social hierarchy. I’ve certainly seen this – even in organizations with a formal hierarchy. Emergent leadership and hierarchy can be a good thing. They can also be a bad thing.
I can immediately think of several teams I’ve worked with were one of the developers – sometimes a relatively junior one at that – emerge as leaders and the team adopted a hierarchy oriented towards that leader. On one occasion that leader was me and I like to think I brought an order and structure which was beneficial. But I’ve seen other occasions were the leader who emerged was at odds with others in the organization with the result of tension.
I expect the idea of emergent hierarchy is immediately recognisable to those schooled in emergent design and behaviour. The question becomes: should organizations accept this? Or should they try to guide it?
In the extreme should an organization fight an emergent hierarchy which conflicts with the aims and goals of the organization? And is it worth the effort?
So far I have more questions than answers. I haven’t suddenly become an advocate for hierarchy but I now recognised this is not a one sided discussion. I plan to write another blog when I get to the end of the book and have had a chance to think through the for and against arguments.
In the meantime I’d love to hear your thoughts and comments, just add them below.
Like this post? – Like to receive these posts by e-mail?
Something my first proper girlfriend said to me has stuck with me my entire life as I disagree with it (mostly). She said that the best way to discover a new band was to see them live first. The reason I disagree is because I get most pleasure from knowing the music I am listening to live - most of the time.
I’m a member of the Bloodstock Rock Society and their Facebook page is often a place of band discussion. Lots of people there were saying how good Insomnium are, but they didn’t do a great deal for me when I listened to them on Spotify. Then it was early 2020, I hadn’t been to a gig since Shakespears Sister in November, I fancied a night out and Insomnium were playing in Norwich. So I took a chance….
From the off they were great live and I really enjoyed it. I came to the conclusion that I must like some of their older stuff as it was the new album which hadn’t done much for me. There were lots of things I like, like widdly guitars, metal riffs and blast beats, but what really lets Insomnium down is the vocals. Death metal vocals, to a certain extent, are death metal vocals, but this guy sounded like he was singing a different song in a different band - it’s the same on the album I tried. If the vocals were more suited to the music, like there are with Wintersun, it would be even better. I also learned that Norwich City’s current start player is from the same town in Finland as the band.
The first thing I did this morning was look up which albums the setlist was from an make a list:
One for Sorrow
Across the Dark
Above the Weeping World
Shadows of the Dying Sun
Heart like a Grave
And then die a little inside at the prices on Amazon and eBay. I think I’ll be playing a lot of Insomnium on Spotify for the time being so I’m ready to enjoy them to the full next time.
The Baron's most recent wager with Sir R----- set him the challenge of being the last to remove a horizontally, vertically or diagonally adjacent pair of draughts from a five by five square of them, with the Baron first taking a single draught and Sir R----- and he thereafter taking turns to remove such pairs.
When I heard these rules I was reminded of the game of Cram and could see that, just like it, the key to figuring the outcome is to recognise that the Baron could always have kept the remaining draughts in a state of symmetry, thereby ensuring that however Sir R----- had chosen he shall subsequently have been free to make a symmetrically opposing choice.
When reading code, starting at the first line of a function/method, the probability of the next statement read being a for-loop is around 1.5% (at least in C, I don’t have decent data on other languages). Let’s say you have been reading the code a line at a time, and you are now reading lines nested within various if/while/for statements, you are at nesting depth . What is the probability of the statement on the next line being a for-loop?
Does the probability of encountering a for-loop remain unchanged with nesting depth (i.e., developer habits are not affected by nesting depth), or does it decrease (aren’t developers supposed to using functions/methods rather than nesting; I have never heard anybody suggest that it increases)?
If you think the for-loop use probability is not affected by nesting depth, you are going to argue for the plot on the left (below, showing number of loops appearing in C source at various nesting depths), with the regression model fitting really well after 3-levels of nesting. If you think the probability decreases with nesting depth, you are likely to argue for the plot on the right, with the model fitting really well down to around 10-levels of nesting (code+data).
Both plots use the same data, but different scales are used for the x-axis.
If probability of use is independent of nesting depth, an exponential equation should fit the data (i.e., the left plot), decreasing probability is supported by a power-law (i.e, the right plot; plus other forms of equation, but let’s keep things simple).
The two cases are very wrong over different ranges of the data. What is your explanation for reality failing to follow your beliefs in for-loop occurrence probability?
Is the mismatch between belief and reality caused by the small size of the data set (a few million lines were measured, which was once considered to be a lot), or perhaps your beliefs are based on other languages which will behave as claimed (appropriate measurements on other languages most welcome).
The nesting depth dependent use probability plot shows a sudden change in the rate of decrease in for-loop probability; perhaps this is caused by the maximum number of characters that can appear on a typical editor line (within a window). The left plot (below) shows the number of lines (of C source) containing a given number of characters; the right plot counts tokens per line and the length effect is much less pronounced (perhaps developers use shorter identifiers in nested code). Note: different scales used for the x-axis (code+data).
I don’t have any believable ideas for why the exponential fit only works if the first few nesting depths are ignored. What could be so special about early nesting depths?
What about fitting the data with other equations?
A bi-exponential springs to mind, with one exponential driven by application requirements and the other by algorithm selection; but reality is not on-board with this idea.
Ideas, suggestions, and data for other languages, most welcome.
In the first part, I described how I set up the basic OpenBSD WireGuard VPN server. I also hinted that I wanted to set up my own validating, filtering DNS server. With a little bit of spare time during the holidays I decided now was a good time as any. Making sure the VPN server […]
“Planning has rapidly diminishing returns: plan less, do more, learn more, redesign governance to kill early and often.”
Happy new year! – There is always a special responsibility that comes with the first blog post of a new year. Fortunately Tom Cagley of SpamCast fame asked me a fantasy question:
If there is one piece of advice you would give to CxO executives what would it be?
There is plenty of advice I’d like to give them, but one piece of advice?
One piece of advice which is generic and cuts across industry upon industry. One piece of advice for all those companies I know nothing about.
Tough. When I eventually came up with my answer I knew I’d have to explain it.
I had to think long and hard. I knew immediately that it would be something on the continuous digital theme. (One piece of advice for budding authors: don’t write long books, I knew this already then I mistakenly wrote Continuous Digital, that should have been four books.)
Eventually I came up with this:
“Planning has rapidly diminishing returns: plan less, do more, learn more, redesign governance to kill early and often.”
I believe this is universally true. Plan anything for long enough and you will eventually plan your way out of doing anything. When I run my Extended XP Game I regularly see teams plan their way out of good approaches to work.
Some planning adds a lot of value. But the rate of learning slows and continues to slow. At some point you aren’t learning more at all, and sometime after that your learning is counter productive. As economists say: there are diminishing returns on the investment.
A little planning adds a lot of value. But each extra minute of planning adds less value than the previous minute. Plan a little, do a little.
In our modern technology driven world two factors make this especially true.
One: learning by doing is faster with modern technology
Technology has advanced: Moore’s Law means I have over 100 times as much power in my MacBook Air as I did in the 6502 BBC Micro I learned to program on in the 1980s. That in turn had more power than the IBM Mainframes of the late 1960s.
That means our tools are more powerful: the Python I programme in today isn’t the most powerful language but it is a damn site more powerful than 6502 assembler and BBC Basic. Add open source libraries and that Python is immensely more powerful than writing in 1960s COBOL.
As a result things that tool months or years to create take hours and days. A week of planning for a OS/360 COBOL program that will take 6 months to write makes sense. A week of planning for a Python program I’ll have running in the cloud by the end of next week doesn’t.
And when I say planning I mean all aspect of planning: research, requirements, schedules, architecture designs and the rest.
Sure a bit of planning makes complete sense. I would be stupid not to make a coffee and think about what I was about to do. But planning is all about learning, is about experiencing the future a little bit. The power of our tools today means that future is a lot closer, and the most rapid way to learn about it is to create it.
Once I reach that future it makes sense to stop, review and plan again. The quickest way to learn is to alternate thinking (that is “planning”) and action (learning by doing.) Do something, see what works, then take time to reflect and learn.
Doing is learning too. The question at any given point is: what is the fastest way to learn? In the beginning that is planning, very soon doing becomes faster.
Now remember: planning time is time, planning delays launch. Keep planning, analysing, talking to potential customers, drawing imaginary project plans or perfecting your architecture (before you start building) all delays the time you will get a product into the market.
That delay is bad because it increases risk: until your product is in the market you are at risk of creating a product nobody wants, or at least nobody will pay for.
That delay means your product will earn less money – thats cost of delay. Potential customers may have found other solutions, competitors may have got there first, or technology advances may render your product obsolete.
Lets be straight: I’m not saying No Planning. A little planning can be really really useful and valuable. So please plan!
What I am saying is: plan a little, do a little. Repeat.
Then stop, reflect, evaluate, and plan a little more before you do a bit. Alternate planning and doing. I’m not original in saying that, the Shewhart cycle (i.e. the Deming cycle or PDCA), says the same and so do half a dozen other approaches.
The problem is: many executives have been taught to plan plan plan. Nobody ever gets in trouble for planning too much and most failures can be traced back to a failure to plan more if you try hard enough. Ultimately, if you plan enough you will never have any failures because you will never do anything.
Which brings me to the last part of that executive advice: “redesign governance to kill early and often.”
Organizational governance is overwhelmingly based on the assumption that we know what we are doing. Only things that are very well understood will be allowed to start. That incentivises people to plan plan plan. And when something does get started there is a bias against closing it down (inertia and commitment escalation).
That needs to change. Since we can’t know in advance we need to be able to react once work is in flight.
Organizations need to be prepared to start work where the outcome is vague. Governance then needs to kill initiatives which aren’t showing promise. Put it another way: the early stage gates need less rigorous and the later ones more rigourous. If governance isn’t killing initiatives often then either governance isn’t working or you aren’t taking enough risk.
Like this post? – Like to receive these posts by e-mail?
. What is the probability of the statement on the next line being a 
