Hey, a quick message for those of you who are listening to this
episode on Spotify. I have a small favor to ask.
Spotify now allows mobile users to rate podcasts.
I would really appreciate it if you can take a quick pause to go
to the Technically Journal podcast page and leave your
favorite show your best rating on Spotify.
It will help me a lot to get this podcast to reach more
people on the platform. Thanks a lot.
So one thing. That I noticed.
When you mentioned. In the beginning, before you
read these three things, is. You mentioned the books have
been written like 12. Years ago and there are still
some things that are timeless and this is something that you
mentioned before we had this talk that we can all learn from
the past. There are many things that stays
relevant. There are many things that stays
true even till now. So what will be some top key
lessons from the past that you think we as programmers covering
the old programmers and new programmers should know?
Why are the things from the past there still stays relevant?
So let's go back to origin story.
So I read a lot of books when I got into software development
was at the end of the 1980s, which is quite a long time ago,
and the world has changed quite a lot since then.
The books that my boss had were from the 1980s and the 1970s,
and I read a lot of these things, so they were kind of
already historical, a lot of them.
But what I found was a surprisingly timeless quality to
some of the books and their advice.
So I was brought up on a lot of ideas about how to think about
code in terms of cohesion and coupling.
We are losing these message. People have got distracted by
guidelines that don't emphasize these properly or have watered
them down in a particular way. Cohesion and coupling.
Cohesion, the degree to which things cohere and naturally hold
together. Now, sometimes people kind of
say, oh, isn't that the Single Responsibility Principle?
Well, not really. It the kind of cohesion.
It's not about responsibilities. The original quote is the Single
Responsibility Principle is actually about single reason for
change. It's nothing to do with
responsibilities. So naming is hard.
We know that single reason for change, but what does that
actually mean? It doesn't really mean much.
It's a kind of cohesion, but there are other kinds of
cohesion. So why people have got fixated
on one kind of cohesion to the exclusion of others, I don't
understand. We should be teaching people
about cohesion. And then again, if we look at
things like the SOLID principles or many of the principles people
describe, they don't talk about coupling, In other words,
dependency management, the degree to which things connect.
And we have far more dependencies in Co bases now.
And for some people when they talk about dependencies, they
are talking about external dependencies.
And you sort of say, oh, dependency management.
Yeah. And they show you all their
external dependencies. Like, yeah, you've got half a
million lines of code here. I'm talking about the
dependencies in the code base, not just outside the code base.
Some people kind of ended up kind of losing track of that.
So coupling, cohesion, these are ideas in the 1970s.
They do not go away. They are fundamental.
There's a lot of things people have been trying to push as
fundamental. Those are coupling.
Cohesion are for us. They are for our benefit.
But by the way, the code doesn't care.
The compiler's just going to compile what you give it.
It doesn't care about coupling cohesion.
The processor you're running on doesn't care about coupling
cohesion. It's just going to execute what
you say, coupling, cohesion for our benefit there so that we
understand, so that we can maintain, so that we can build.
That's what that's about. So for me, these are really old
ideas and more appropriately timeless ideas.
They don't go away. We should be building on them,
not trying to muddle a message. Therefore, paying attention to
this stuff is important and I think that's what a lot of
people are trying to do when they reiterate or try and
reframe these, they're trying to get that message out.
But then there are other things that I think we haven't paid
attention to Co quality. So these days the popular way of
framing things in terms of issues of Co quality is in terms
of technical debt. Now that's not really quite
right, but it's not a bad metaphor, although we do misuse
it a little bit. But if you look back at the
past, people have been talking about Co quality issues forever
since they realized there was an issue.
One of the things we've learned is that this really does make a
difference to the future of development.
So how can we expect people to easily add things in future?
Put it another way, most developers are living in the
past. When somebody sits down in front
of a piece of code, they are projecting themselves into the
past. Maybe it was the past them,
maybe it's past somebody else. But when people are working on a
code base, they are spending, let's say, in an 8 hour day,
they are spending about 7 to 7 1/2 hours dealing with the
problems of the past. Oh, I'm trying to add a feature.
Yeah, I can see you're trying to add a feature.
But actually what you're doing is you're grappling with the way
that the code has evolved. You're actually fighting the
past because you know that you want this feature to be
different, but you don't understand the code that's
there. Or you're fixing a bug.
Fixing a bug is living in the past.
Trying to understand code that was written that's living in the
past, working around something that's living in the past.
Writing a test for a piece of code that doesn't have a test
that's living in the past. In other words, these are all
things that should have been solved in the past.
People spend most of their time living in the past.
And I'm not saying that we don't do that or shouldn't do that.
We're there's always going to be some percentage.
But I think that actually defines most of what programmers
do. Very few developers actually
spend their time genuinely adding value to code bases.
They spend their time compensating for the problems,
the past. And this is a distinction that
systems thinker John said and highlights as value demand
versus failure demand. The demand for your work.
How much of your work is actually spent on dealing with
problems that have arisen in the past and more importantly for
me, problems that are actually solved problems.
So let me bring something more up to date.
So refactoring that I think for many people they just assume
that part of the software development landscape, actually
until the late 90s, that wasn't really a known term or a popular
idea. In one sense, we've done really
well here. But if you go back and you look
at Martin Fowler's original book on refactoring, or the original
writings and terms of Extreme Programming, which really
focused trying to bring refactoring as forward to the
front as it were. So refactoring in many people's
heads exists in one of two spaces.
Oh, refactoring. That's a big work we do on our
legacy code base. You know, refactoring is to do
with legacy, is to do with bad code.
And then the other one is, oh, refactoring.
Yeah, that's the shortcut key that gets me to rename things
and occasionally Extract method. And it's just like actually
refactoring is a design practice and it's not always about bad
code. Refactoring is the idea that
your software is supposed to be sought, and therefore when you
come up with a better understanding of something, you
oh, wait a minute, there's a better way of writing this.
I should be able to reshape it easily so that I reflect my
current thinking instead of using yesterday's thinking.
I've got my current thinking. I keep the code fresh.
Therefore it's constantly in the state of improvement and
response. Because we're always operating
with incomplete knowledge. We can never know everything.
It also allows me to be more forgiving, if you like.
Yeah, we got that wrong, but now we can make it right.
And that's not a big deal. That's part of what we call
software development. It's not a separate thing.
It's not a separate activity I have to ask somebody permission
for. It doesn't have that idea
though. It's just part of the flow.
And so I think that although you open up a modern IDE, it's got
refactoring there. Most people don't use that apart
from rename kind of have a standard Joe.
What I point out to people, it's just like, isn't it great these
days? We don't have legacy code
because when I joined the industry, we had legacy code.
In fact, the term legacy was first used in 1989.
So the term legacy applied to code was actually the year that
I joined the industry. And I say, isn't it great these
days that we don't have legacy code because we've got the
refactoring tools that eliminate most of all the problems, you
know, but people used to complain, oh, we've got this
method, it's too long. It's so good that we don't have
that problem anymore because we have ways of breaking up
methods. And people say, Oh yeah, classes
that are too big. Again, we don't have those
problems because you can extract class.
Eventually, kind of people get the idea that I am joking.
And actually I'm asking a deeper question.
We have these tools. So why do we still have all of
the problems that these tools solve and what that actually
teaches us? It was not a tooling problem.
That's what it teaches us. We have given everybody
everything they need. So in other words, this is the
interesting thing. For most software, we know how
to deliver it with low defects, with low unmanaged technical
debt, and to deliver it close to being on time.
These are solved problems. By the end of the 20th century.
Every single one of the problems I've just mentioned was Sol, and
yet we still struggle with them. So for me, that's the bit of the
past you want to live in. What are the good ideas?
We are still not applying consistently.
I still have to discuss with people whether or not they
should test. That shouldn't even be a
discussion. OK, you write tests if you can
get high statement coverage, well done.
There's other forms of coverage, but that should be the minimum.
When people say, Oh yeah, we've got less, do you have 100%
statement coverage? No, no, we're at about 50%.
OK You do know that 100% statement coverage is really
easy to get and people are always shocked by that.
It's just like, well, yeah, you just do test driven development.
That's it. People who do TDD don't worry
about coverage. Or rather, they worry about when
the needle dips below 100 because that normally means
there's some dead code. This statement coverage is only
interesting for people that don't do TDD or other forms of
continuous testing. The idea if you are doing
continuous testing, coverage is not interesting.
It's a figure that you always expect to be high because you're
always writing your code and your test together.
Maybe you lead with the test TDD style.
This is a solved problem. We solved this years ago, but
people still struggle with it. They try to justify having to
run tests. I was talking to somebody
yesterday from Microsoft about this whole thing about why is it
that people are not using static analysis and high warning levels
more? There are reasons, but they're
not very good ones. Why do people not have clean
builds? Once you solve all of these, it
leaves you with the real problems that are interesting
once you've cleaned up the bad code, Once you've cleaned up all
of this kind of stuff, you will still have legacy, but that
legacy will be there for a different reason.
That legacy will be leftover decisions from the past.
Your challenge is now to deal with like, yeah, we took this
decision, but the technology landscape or the requirements of
MU. So that decision is no longer
appropriate. It's not a bad decision, it's
just doesn't fit the world any. And we wrote this code in good
faith, but now it's no longer right.
So we need a better fit for the code in the world.
So don't worry. Once we've solved all the
problems, there are still plenty of problems.
But what I'm saying is that most of the things that people have
said, hey, modularize your code, use a coherent paradigm, have
less state mutability. That doesn't mean you have to go
do functional programming. If you're in a functional
language, that's absolutely brilliant.
If you're in a language that really nudges you in that
direction, that's great. But even as somebody who's
worked in C and Fortran, I'm going to say you don't have to
have highly imperative code. That's never been a great idea,
and you're not forced into that. There are simple techniques you
can deal with. Modular as you code use various
techniques. A class is a module in this
sense. It is a modular construct.
Any form of data abstraction is a modular construct.
Micro services and modular constructs at a larger scale.
But the idea is, if you think that micro services are going to
solve your poor modularity in your code, they're not.
When everybody says, hey, we're doing micro services because
it's going to improve the structure of our code, well you
don't need micro services to do that.
Micro services solve a very specific problem related to
deployment and scaling. That's what they're really good
at. If we have had so many paradigms
over the last few decades that are about how to organise your
code, you don't need any more. You've got every single tool.
And if you can't do it with that, then you should take a
step back, put the mouse down, step away from the keyboard and
go wait, what's really going on here?
What is it that we are missing as a team collectively to
reinforce these practices? So yeah, the past is an
interesting place. We get drawn back to our
mistakes in the past, but we fail to learn from our
successes. So that would be my general
advice on this one. Listening to your explanation is
very fascinating because a lot of developers these days chase
this hype driven development, right?
Oh, there's the new cool technologies, new framework, new
libraries, new paradigms like micro services, event driven and
things like that. But if we look back to the past,
there are probably so many theories that still stays
relevant. And in fact, I noticed some of
these thought leaders in the tech industry like Dave Farley,
Robert Martin, Uncle Bob. They wrote books titled like
Modern Software Engineering and Clean Craftsmanship.
But if you look at the things that they are advocating,
actually it comes from the past. The same fundamental things that
stays relevant even up until now.
So I think the key message here I want to emphasize is that for
developers, please go back to the fundamentals, don't always
chase the new shiny things. There are still things that we
can probably master to become a better developers.
Yeah. And I think the value is that
when you understand though, it gives you a more solid
foundation. And when something new and shiny
does come along, you now have a more objective assessment.
You can separate out and go, OK, yeah, this is building on
foundations. There's nothing new here.
And then you can look at the bit that actually is shiny and go,
this is the value of this. Or you may say, wait a minute,
there is nothing shiny here. This is just repackaging the
past and also it's mistakes. So maybe let's not do this one.
It gives you a more objective sense.
Of course, most people in technology get into technology
because they like the excitement of something.
So we have to kind of watch ourselves a little bit on this.
We are our own worst enemy at this one.
So one thing that I always find fascinating also because there
are tools that are built by developers that makes things
easier for us to. Churn out code.
But not necessarily comply with this cohesion or this coupling.
So think of it like the framework, software frameworks,
right? So I think that's also another
thing that is fascinating. Like we tend to one, shortcuts
deliver something faster, but not adhering to the good best
principles that software should be written in.
So Kavlyn, another thing that you're very popular in, it's
what people call Kavlyn Haney's screen, right?
You can see in Kavlyn Haney's Twitter.
Just look at what we call software failure.
And these are normally public software failure.
And people just send, you know, pictures of these software
failures to Kavlyn. So maybe the first thing is tell
us what the story is all about. How come people actually send
all these things to you? So the story goes back a long
way. I used to take screenshots.
Whenever something crashed on my machine, I'd take a screenshot
of it, and sometimes I would integrate it into a torque.
Then of course, phones have cameras.
So I started taking pictures of software failures in public
places, because software runs the world, but it doesn't always
run it in the way that we wanted to.
There's a lot of reboot screens and screens which trace very
elegantly the whole text stack that's just crashed.
I started taking photographs of these, and again, I'd
incorporate those into talks or I'd just kind of put them on my
screen when running a workshop. A good source of entertainment,
but also going back to this question of quality as something
I've always had an interest. It's a reminder of, like, yeah,
in the tech space, we have a certain responsibility.
We are creating things that crash.
We are creating things that don't work.
A bug isn't personal inconvenience to you or a
configuration issue is a personal inconvenience to you,
or it just becomes a ticket. The thing is to realize that it
exists in the world. It's not an abstraction.
It's actually exists in the world.
It's amusing sometimes, but also it's probably preventing
somebody else being able to do something.
So I kind of highlighted these. Then as a result of this, people
would then start emailing me these things.
Then we hit the social media area.
So it's much easier. They have to e-mail me, they can
just tag me. So this was becoming a popular
thing on Twitter in particular. What I would do, because that's
a very public space, is that I would just retweet these.
Then people started making a point of doing this.
And in 2016, somebody actually started saying, oh, a kevlan
Henny screen because it had reached a particular point.
And so that's how my name got associated with it.
From that point, there's even somebody put an entry in Urban
Dictionary and there's even a mention in the register of this
stuff. So that's kind of an interesting
thing. I was also asked by somebody
Kevlan, what does it feel like to have your name associated
with failure. So I think it's an interesting
way of looking at it. It's just like, yeah, I don't
'cause these screens, but it is interesting because it's a
reminder for me that, you know, when we deal with software, when
we develop it, and when we deploy it, we are part of a
larger system where our failures in software are no longer about
us. They are about other people.
They become very visible. And in a world that runs on
software, that becomes a prominent point.
Some of them are quite revealing in a way that you don't want to
be revealing. Like I said, sometimes you get a
complete stack trace. In fact, I saw one yesterday
which was quite interesting. The stack trace was not visible
even though there was an error. Because whoever created this had
the wisdom to say, you know what, we're showing our internal
structure that can be used against us from a security point
of view. You discover that somebody's
using an unpatched version of something, you go, Oh yeah,
that's interesting. I've got a new attack vector
there. But it also tells us something
about the organisations that run them.
I still get images of Windows XP boot screens and failure
screens. Windows XP has been out of
support for a very long time. Again, we're living in the past.
A lot of the world is running on stuff that everybody thinks they
left behind, but there isn't it actually all there.
We have a responsibility there that we need to get a little
better at this, but then we also get the obvious programmer level
bugs. It's just like, yeah, we should
have perhaps configured that a little more carefully or tested
that more thoroughly. It tells us about us.
That's what a lot of these things do.
But what is also interesting is that sometimes when people tag
me, particularly with something like public transport, they will
also tag the public transport company.
And some of the time the public transport whoever's on Twitter
at that point will sort of say, Oh yeah, sorry about this, or
yes, we saw this problem. It's been resolved.
Or please tell us more because, you know, this is embarrassing
for us. So it's also a public service at
that level? I hope you all the programmers
who build systems, never had a chance for your systems to be
sent to Kevin Haney for. Failures.
But I think the story that you just told, right, I think
there's a lot of things here that are insights.
So when you deploy software, especially for public systems
like public transport, airports, sometimes I see all elevator.
So there are a lot of responsibilities.
Software failure can impact a lot of people.
These kind of things are definitely for one thing is
funny, yes, but at the other end it's something for us to ponder
about software failures to be treated more seriously.
I hope you enjoyed this short clip from Technically Journal
Favorite Playlist. If you find this episode useful,
please help share it with your friends and colleagues who you
think would also benefit from listening to this episode.
And if you want to listen more from this conversation, please
go back and listen to the original full conversation with
my guests. Stay tuned for the next Techly
Journal episode, and until then, goodbye.