This talk introduced LLMs to software developers as a new kind of processor with remarkable capabilities, framed within the history of computing.

It began with a brief overview of the LLM breakthrough, highlighting the transformer architecture and scaling laws.

The session then offered software engineers a practical mental model: thinking of LLMs as a new type of processor, analogous in some ways to a CPU.

Treating your mature enterprise product carelessly will get your business into deep trouble, but gold plating a new product, before you are sure that you are building the right thing, can bring your venture to a premature end.

Although this might seem like common sense, most debates about software practices are still based on the assumption that there is one best practice for all contexts. It took us few failed software product start-ups and unstable mature products to learn this, and how to adjust our way of work, depending on the business context.

This idea has recently been expressed in various guises by a few prominent thinkers, like:

• Simon Wardley’s Value Chain Mapping
• Kent Beck’s 3X - Explore, Expand, Extract
• Jeff Patton’s Dual Track Development - Discover -> Develop

In this talk I will take you through new ideas on the topic and important differences in the 2 contexts, share stories of our own failures and successes, and give you some practical advice on adjusting your approach for the context.

This talk is for any software professional who cares about business value.

In order to escape the common traps of software development, teams and managers need to understand the consequences of their decisions - they need to understand the dynamics of software engineering. This is not an easy task and we need solid help. We need maths!

In this talk I explore a few equations that describe dynamics in software engineering, which can help us see the forest from the trees. I also cover some modern practices - and show how software engineers can get back control of their delivery.

The problems addressed include:

• Deadlocked by Dependencies: Inability to deliver due to waiting on something
• Code-Degeneration: Code changes become more difficult over time
• Congestion: Slow, unpredictable delivery even though we are very busy
• Firefighting: We know what we should do, but we don’t have time to improve

Although software engineering has become crucial to our modern society, it is still a new and often misunderstood discipline.

One of the most harmful misconceptions is that programming and testing are similar activities to construction in mature engineering disciplines, performed after the design has been completed.

In this talk I will give the audience a fresh look at software engineering, inspired by a 1992 article by Jack W. Reeves: “What is design?” I will show how software product development is a creative, collaborative process involving the create creative energy of all the role players in a team (including UX, BA, Dev, Test, Ops).

Finally I will revisit ideas from XP (Extreme Programming) and just show how cool this software design can be when we do it together as a team.

Choosing the wrong mobile tech stack sets you up for a world of pain. But how do you select the right one from a plethora of current options?

As an iOS developer I am convinced that a carefully designed native app provides the best user experience. So why would we choose Ionic2/Angular2 on Cordova (a bleeding edge Hybrid JavaScript framework) for our latest mobile app? In this short talk I will share our thinking and experiences on the current landscape of mobile stack options.

I will introduce the contenders: Native (iOS and Android) vs Semi-Native (Xamarin and React Native) vs Hybrid (Ionic2/Angular2 on Cordova) vs Web. We will then go through some of the prominent tradeoffs between the different options: cost, reuse, single language, speed and user experience, device support, learning curve.

This should give you some (opinionated) guidelines to choosing the right mobile stack for your particular app.

Dealing with an ageing code base is one of the hardest challenges that software development teams face. Legacy code bases can slow teams to a crawl, and therefore it is critical to solve this on the road to agility. Software rewrites fail at alarming rates! Refactoring – a safer approach – has emerged as the de-facto technique to tackle this challenge.

This session we will equip attendees with techniques and lessons to help them refactor more effectively. We will share our experience gained while working with various software teams, from startups to mid-sized organisations, that attempted to rescue their legacy from impending doom.

You will learn how to justify the investment in refactoring legacy code to product owners; when and how to apply different refactoring workflows on legacy code; and practical tips to avoid common pitfalls when refactoring code.

Here is a list of classic articles and books that have informed my thinking on software engineering.

This list does not include my list of (great) programming, philosophy or management books, but speaks more to understanding and managing software development on a higher level - as I believe most software endeavors succeed/fail before a line of code was written.

A note on learning:

Almost all I know and believe about software comes from experiences and observations in delivering software, but that does not discount the value in these tomes. I typically learn a fundamental principle by first observing a phenomenon in various environments, and then, when I come across a great study or article which clearly expresses and justifies the principle I get that “AHA!” moment where deep understanding is formed. E.g. seeing estimation inaccuracy occur 100s of times, and then reading Don Reinertsen’s description of variability in product developments gave me a big “AHA!”.

Too be honest, so much in software engineering isn’t obvious or intuitive and I initially miss the messages in books that were not pre-empted by my experiences (XP being a prime example).

Here goes:

Approach and principles:

• Managing the Development of Large Software Systems, Royce (1970) The paper that introduced waterfall gave a clear warning about its risk and showed (rudimentary) ways to introduce feedback
• The Mythical Man Month, Brooks (1975) *
• No Silver Bullet, Brooks (1986)
• The New New Product Development Game, Takeuchi&Nonaka (1986)
• Extreme Programming Explained: Embrace Change, Kent Beck (1999) *
• The Agile Manifesto (2001)
• Agile Software Development with Scrum, Schwaber&Beedle (2002) *
• Lean Software Development: An Agile Toolkit, Poppendiecks (2003)
• The Principles of Product Development Flow, Reinertsen (2009)

Building the right thing

• User Story Mapping, Patton (2014)
• The Lean Startup, Ries (2011) - to find out if we are building the right things often needs more than just detailed analysis, we need to experiment, but do it fast so that we don’t run out of time/money.
• Specification by Example, Adzic (2011)
• I need more on Interaction and User Experience design! **

Building the thing right

• Decomposing Systems into Modules, D.L. Parnas (1972)
• What is Software Design?, Reeves (1992)
• Refactoring, Fowler&Beck&Brant&Opdyke&Roberts (1999) - Code is design and design should be evolve
• Test Driven Development: By Example, Beck (2002) *
• Domain-Driven Design, Evans (2003) **
• Continous Integration, Fowler (2006)
• Clean Code, Martin (2008)
• Continuous Delivery, Humble (2010)

Being a professional developer

• Code Complete, McConnell (1993)
• The Pragmatic Programmer, Hunt&Thomas (1999)
• The Art of Unix Programming, Raymond (2003)
• The Software Craftsman, Mancuso (2014) **

People, teams, systems and environment (still have a lot of reading to do here!)

• Drive: The Surprising Truth About What Motivates Us, Pink (2011)
• The Five Dysfunctions of a Team: A Leadership Fable, Lencioni (2002)
• Peopleware, DeMarco&Lister (1987) **
• Leading Self-Directed Work Teams, Fisher (1993)
• Out of the Crisis, Deming (1982) **
• An Introduction to General Systems Thinking, Weinberg (1975) **
• Biomatrix: A Systems Approach to Organisational and Societal Change, Dostal (2005)

*Books I have to read again, because I didn’t realise their significance when I read it, and therefore didn’t absorb the content.

**Books I have only skimmed that are still on my must-read.

“Nothing is more powerful than an idea whose time has come.” — Victor Hugo

“Am I going to be bored or enlightened?” was the question I asked before attending Agile 2015, my first international software development conference as a speaker.

I was enlightened. Almost overwhelmed. This is why.

I started conversing with people at the Agile Coach Camp open spaces: agile coaches, industry celebrities, hardcore programmers, change management consultants, authors, community builders, philosophers, eccentrics. A diverse bunch, but all open to debate, share, learn and apply. I’ve never experienced anything like it.

For a full week it did not stop. Topics ranged from 21st century democratic organisations to games to error handling code. The scheduled talks were good, but the informal conversations and debate were much better.

That’s great. What did I take out of all this?

How ideas in our industry work

One thing is a sense of how ideas in our software industry works, how they emerge, spread and get accepted. For example, how did DevOps get widely accepted and become de-facto?

I drew the following conclusions:

1. Ideas get born, live and grow in a professional community
This became apparent to me after speaking to a few of authors and comparing how I experienced the book versus the conversation. An idea printed in a book creates the illusion of immortality of the ideas in it. But ideas are living things in a sense: if the community rejects/forgets it, it is dead in a way (seen as false or invalid). Ideas are mortal and grow by virally replicating through professional networks.

2. Ideas are born from other ideas
The illusion of “the lone genius that figured it out, out of thin air” is often misplaced. Ideas are mostly built from other ideas, maybe a novel combination or reconfiguration.

3. Ideas often have champions
Just because an idea is not completely novel does not mean an idea does not have a champion. There is more than often an thought leader that promotes and nurtures an idea, even gives it a name. Sometimes even takes credit for it all. I call this persona the thought leader.

Do these 3 points apply to industries outside software? I think so, but the community nature of ideas seems more pronounced in software, since software practices are still changing rapidly (less stable than say, accounting), and we have no central “authority” (there is no “Ivy League Old Boys Club” or organisation that controls which ideas get accepted).

How to become an industry thought leader

The above made me think more about what makes an industry thought leader.

We had the privilege of having conversations with (in no particular order) Jeff Patton, Michael Feathers, Diana Larson, Ron Jeffreys, Dave Hussman, Chet Hendrickson and other well known coaches and authors – people I see as thought leaders in our industry (thanks Declan Whelan for making a few great conversations happen).

These discussions made me realise that I had some misconceptions. I learnt that a good thought leader often has the following traits:

1. A thought leader is a community leader
Giving credit is like spreading seeds for an idea. All of the above people were the most generous in sharing, giving credit, giving back to both people wanting to learn and people wanting to contribute new ideas. They almost always gave credit wherever they could, and promoted other people and their ideas where they could. The persona of a generous, loved community leader emerged across the board. This surprised me. I now think that this is necessary for ideas to flourish, especially for their own ideas which they are promoting.

2. Practice, practice, practice what you preach. Then show results
Practicing your ideas, and having great case studies on how you applied your thinking to various situations is crucial to getting credibility and buy in from the professional community. You obviously have to show that it works, and understand the limitations when facing better than anyone. If you have this, your idea can quickly get traction.

Charisma can get attention, but you need to show results to be widely respected – I am surprised how many speakers miss this part.

There are ways to do this without being everywhere at once. For example, Martin Fowler seems to tap into the experiences of many teams in his organisation.

3. Know how to receive critique and disagree respectfully
Critique is necessary to heathy ideas. Thought leaders know how to receive, absorb and respond to critique, without getting defensive. Critique is the hammer and anvil that hardens and moulds your ideas (or breaks ones that should not be). Your arguments will grow stronger and stronger if you consider critique carefully.

That said, it is often necessary to disagree with other ideas to draw distinctions and clarify your ideas. Thought leaders know how to do this well: know the pros and cons of the idea you are criticizing before jumping to conclusions. Rather defer judgement or even ignore arguments of other ideas you do not understand. Resist the temptation to be a “hater” in your critique, don’t use straw men or appeal to authority. “Hater” behaviour might get a bit of attention, but you ultimately loose respect and get alienated. Alienation means starvation of your ideas.

4. Bring experience from other fields
This point is about where good ideas come from. A lot (but not all) of the fresh, novel approaches come from applying ideas from other industries. Examples are plentiful, but most notably Lean Manufacturing, Life Coaching, Biology, Other Engineering Disciplines, Philosophy, Improvisation Acting, Industrial Design, Mathematics, Art and Music, Sci-Fi and a bunch more.

Having varied experience and a balanced life with varied interests, puts you in a better position to stumble across the next big thing.

5. Focus on one or two ideas at a time
Even though a thought leader might have many interests and ideas, to be a thought leader you have to be a centre of discussion on a contemporary theme, and thus have to focus on that area, at least your public interactions. You have to write and speak about it.

Conclusion

I don’t think we all have to strive to be celebrity authors, but realising that ideas live in a community, and becoming an active idea participant, a good citizen, in this community, makes you a thought leader and makes our industry better.

Or you can just build stuff.

Thanks to Martin Cronje (a few of the ideas in this post was his), and Declan Whelan (who made sure good conversations happened and ideas spread)

As a software engineering coach part of my job is to help teams become more effective. To this end, it is sometimes useful to employ concepts from self-help books, but I don’t always enjoy reading these, they often stretch a few insights into endless anecdotes.

The Blinkist app really helped me with this dilemma last week; I managed to cover the key insights of 40+ books in just a few days. Good job Blinkist.

During this self-help binge, I noticed a few ideas being repeated in a wide variety of books, especially the more core principles.

Here are a few insights that struck me as reoccurring, as well as the books they came from:

On being effective:

• The best way to be more effective is to focus only on highest impact things next. The 7 Habits of Highly Effective People (First things first), The 80/20 Principle, The 4-Hour Workweek and others.
• Be more productive by doing only one thing at a time. The Pomodoro Technique, Getting Things Done, The Principles of Product Development Flow and others.
• Define a simple system of prioritised queues with small work items to visualise and manage work. Getting things Done, The Principles of Product Development Flow, The Pomodoro technique.
• Have goals: define explicit goals and values and measure your progress against them. Most of the productivity books I read have this idea in some form; I liked what Challenging Coaching said on it.

On becoming a better thinker / communicator:

• People inherently don’t make rational decisions/predictions – be aware of your innate cognitive flaws. E.g. we are intuitively bad at stats. Thinking, Fast and Slow, The Black Swan, Predictably Irrational.
• Practice can make hard things automatic and frees your mind up to innovate. Thinking, Fast and Slow, Outliers, Mastery.
• A story with a protagonist and an antagonist is the best format for conveying information in presentations, specifications, etc. The Presentation Secrets of Steve Jobs, User Story Mapping.
• Surround yourself with people you can learn from. Mastery and many others.

On adapting and learning:

• Managing well entails putting frequent, lightweight, honest feedback mechanisms in place at various levels. The One Minute Manager, The Lean Startup, The Principles of Product Development Flow, Challenging Coaching and others.
• Build small versions of your product first and get feedback from early niche, adopters. The Lean Startup, Crossing the Chasm
• Become good at adapting to change quickly, or die. The Innovator’s Dilemma, Who Moved My Cheese

On finding opportunities

• Build and contribute to your professional network; it’s a more secure structure than a company. The Tipping Point, Coffee, Lunch, Coffee, Never eat alone
• The Internet and social media have opened up marketing for a bigger variety of products. The Long Tail, Purple Cow

I changed my mind on this recently, and here’s why.

There is a sentiment that developers have to type really fast because we “type code for a living”.

I’ve long rejected that idea, and not just because lines of code is the worst possible metric for productivity. My main reason was that a good dev workflow normally entails much, much more reading than writing. Also, communication skills, design skills, etc. seem more important to me. I thought fast typing was merely a nice to have, and I never really invested time into improving mine.

But reading the great book “Thinking, Fast and Slow” by Daniel Kahneman showed me a flaw in my view (there’s so much substance in that book, I’m sure I’ll get many more insights from it).

The insight is this:

• Explicit, conscious thinking (which I believe paramount to development) takes a lot of mental energy.
• Like physical stamina, we literally have a limited pool of mental energy. Any task that needs our conscious attention depletes our mental stamina, leaving us with less good thinking.
• Unconscious, automatic processing takes less of a strain (like strolling or breathing).
• Therefore, in order to do more good thinking (as is required in solving programming problems), we need to minimise non-automatic activities.

From this we can see that an activity like correcting a typing mistake will tap our “thinking stamina”, but when typing becomes fully unconscious/automatic it will free up some space for productive problem solving. Hence, it’s important that we learn to type automatically (fast is just a nice side effect of automatic).

This line of thinking can be taken much further than just typing. Anything in our dev environment that is explicit and not automatic, like looking for a menu with some function, or doing an explicit compile, will waste our mental stamina. It is therefore really important to:

1. Know your dev tools, including common shortcuts and navigation tools. Keeping it simple is a easy way to achieve this. This has a similar benefit to automatic typing.
2. Cut out explicit tasks. First thing that comes to mind is compiling. The Ruby and other dynamic lang peeps have been doing this for years, continuously running tests in the background that shows you the impact of changes, instead of a compile, run action. Some great tools in static world, like Resharper and NCrunch helps here. Another is deploying - the whole continuous delivery movement applies here. Tools like JRebel in Java world can also help.

In summary: as a developer, always find ways to reduce explicit, non-automatic tasks that draw your attention. I, for one, will take my environment and skills like typing more seriously now.

Bug, loop and patch - these words have been part of programmer lingo for decades. On my recent trip to the US east coast I stumbled across their origin:

The Harvard Mark I aka the IBM Automatic Sequence Controlled Calculator!

This amazing machine was one of the first programmable computers. I’ll tell you more about this monolith at the end of the post.

“Loop”

The original (mechanical) loop. The program is a long paper tape with holes punched in and runs in this loop. Conditional branching is not supported (no gotos, jumps); you just have one long while (true).

“Patch”

See the actual patch. A correction is made by literally patching a piece of the tape and punching new holes in. Fix your code with duct tape!

“Bug”

The classic! This “bug” was found on a Mark II mechanical component, so not really a program error. It must have been working on my machine.

More..

Tidbits I found interesting:

• It started computing 70 years ago!
• It was Steampunk! Ok, I mean it was electro-mechanical. The inventor Howard Aiken basically built a Babbage engine on steroids.
• John Von Neumann used it to help design the atomic bomb. Seems most of our high-tech was born in that war.
• The number system was decimal, not binary. So you could use all your fingers to count.
• It ran solidly for 15 years. Seems Moore’s Law does’nt apply to mechanical computers.
• The inventor did not give attribution IBM, who funded and built large parts of it. I guess after this IT companies started employing lots of lawyers.

The machine is on display at the Harvard University Science Center (where I took these photos). Hope you enjoyed this as much as I did.