Kevlin Henney
Software Development, Consultancy, and Training
Curbralan
location_on United Kingdom
Member since 1 year
Share
Kevlin Henney
Specialises In
Kevlin is an independent consultant, speaker, writer and trainer. His development interests are in patterns, programming, practice and process. He has been a columnist for a number of magazines and sites and has been on far too many committees (it has been said that "a committee is a cul-de-sac down which ideas are lured and then quietly strangled"). He is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also editor of 97 Things Every Programmer Should Know and 97 Things Every Java Programmer Should Know. He lives in Bristol and online.
-
keyboard_arrow_down
Cool Code
60 Mins
Keynote
Advanced
In most disciplines built on skill and knowledge, from art to architecture, from creative writing to structural engineering, there is a strong emphasis on studying existing work. Exemplary pieces from past and present are examined and discussed in order to provoke thinking and learn techniques for the present and the future. Although programming is a discipline with a very large canon of existing work to draw from, the only code most programmers read is the code they maintain. They rarely look outside the code directly affecting their work. This talk examines some examples of code that are interesting because of historical significance, profound concepts, impressive technique, exemplary style or just sheer geekiness.
-
-
keyboard_arrow_down
Agility ≠ Speed (Perth)
60 Mins
Workshop
Advanced
Velocity. Sprints. More points, more speed.
An obsession with speed often overtakes the core values of agile software development. It's not just development of software; it's development of working software. Sprints are not about sprinting; they're about sustainable pace. Time to market is less important than time in market. Full-stack development is normally a statement about technology, but it also applies to individuals and interactions. The full stack touches both the code and the world outside the code, and with that view comes responsibility and pause for thought. Doing the wrong thing smarter is not smart. The point of a team is its group intelligence not its numbers. Is scaling up the challenge, or is scaling down the real challenge?
The distraction and misuse of speed, velocity, point-based systems, time, team size, scale, etc. is not the accelerant of agile development. Agility lies in experimentation, responsiveness and team intelligence.
-
-
keyboard_arrow_down
Workshop - Paradigms Lost, Paradigms Regained: Programming with Objects and Functions and More
480 Mins
Workshop
Intermediate
It is very easy to get stuck in one way of doing things. This is as true of programming as it is of life. Although a programming paradigm represents a set of stylistic choices, it is much more than this: a paradigm also represents a way of thinking. Having an only way to think about problems is too limiting. A programming paradigm represents a set of patterns of problem framing and solving and contains the ingredients of software architecture. As Émile Auguste Chartier noted, there is nothing more dangerous than an idea when you have only one idea.Perhaps even more problematic than being stuck with a narrow view of paradigms is being stuck with a dysfunctional view of each paradigm. For instance, many developers working in languages and frameworks that support object orientation lack a strong idea of the principles of interaction, data abstraction and granularity that support an effective view of OO, and instead surround themselves with manager objects, singletons and DTOs.During the day we will explore the strengths and weaknesses of different programming styles, patterns, paradigms, languages, etc., with examples and opportunity for discussion. -
-
keyboard_arrow_down
Workshop - Paradigms Lost, Paradigms Regained: Programming with Objects and Functions and More
480 Mins
Workshop
Intermediate
It is very easy to get stuck in one way of doing things. This is as true of programming as it is of life. Although a programming paradigm represents a set of stylistic choices, it is much more than this: a paradigm also represents a way of thinking. Having the only way to think about problems is too limiting. A programming paradigm represents a set of patterns of problem framing and solving and contains the ingredients of software architecture. As Émile Auguste Chartier noted, there is nothing more dangerous than an idea when you have only one idea.Perhaps even more problematic than being stuck with a narrow view of paradigms is being stuck with a dysfunctional view of each paradigm. For instance, many developers working in languages and frameworks that support object orientation lack a strong idea of the principles of interaction, data abstraction and granularity that support an effective view of OO, and instead surround themselves with manager objects, singletons and DTOs.During the day we will explore the strengths and weaknesses of different programming styles, patterns, paradigms, languages, etc., with examples and opportunity for discussion. -
-
keyboard_arrow_down
1968
50 Mins
Talk
Intermediate
It’s half a century since the NATO Software Engineering conference in Garmisch. How are we doing? Are we nearly there yet? Or is there no there there?The world of software development has changed so much and in so many ways since 1968 that it’s difficult to imagine what we could learn from the past, but it’s learning rather than imagination that’s the constraint. There was no shortage of imagination, insight and inspiration in the 1960s and 1970s, and in many ways the apple of 21st-century software development has fallen disappointingly close to the tree of the past.So let’s turn back the clock to see what we could have learned from the past, what we can still learn from the past and what the future might hold in store for code and its development. -
-
keyboard_arrow_down
1968
50 Mins
Talk
Intermediate
It’s half a century since the NATO Software Engineering conference in Garmisch. How are we doing? Are we nearly there yet? Or is there no there there?The world of software development has changed so much and in so many ways since 1968 that it’s difficult to imagine what we could learn from the past, but it’s learning rather than imagination that’s the constraint. There was no shortage of imagination, insight and inspiration in the 1960s and 1970s, and in many ways the apple of 21st-century software development has fallen disappointingly close to the tree of the past.So let’s turn back the clock to see what we could have learned from the past, what we can still learn from the past and what the future might hold in store for code and its development. -
-
keyboard_arrow_down
1968
50 Mins
Talk
Intermediate
It’s half a century since the NATO Software Engineering conference in Garmisch. How are we doing? Are we nearly there yet? Or is there no there there?The world of software development has changed so much and in so many ways since 1968 that it’s difficult to imagine what we could learn from the past, but it’s learning rather than imagination that’s the constraint. There was no shortage of imagination, insight and inspiration in the 1960s and 1970s, and in many ways the apple of 21st-century software development has fallen disappointingly close to the tree of the past.So let’s turn back the clock to see what we could have learned from the past, what we can still learn from the past and what the future might hold in store for code and its development. -
-
No more submissions exist.
