All the latest news and views from the world of Java

The Podcast

Podcast 9 : UML

20-Oct-2017 in Podcasts

Richard and Matt talk about their previous experience with UML and wonder if it still has a relevance for modern Agile projects.

Despite Matt's valiant attempts, Richard fails to have a rant this week. But, he does manage to somehow squeeze in a reference to the "Comprehensive Super Mario Bros. Disassembly" which is quite an achievement on a UML talk (gist.github.com/1wErt3r/4048722).

We had a faulty microphone on this podcast so we're sorry about the sound quality - will be improved next time!

Transcript

 

Richard:All right then. Am I going to start again?

Matt:I'll start.

Richard:Oh, okay.

Matt:Mm-hmm (affirmative). “Alexa, play the latest episode of the All Things Java podcast”. Now, at this point, Alexa will probably complain and say it can't find it, because I've not got that wording exactly right. Welcome to episode nine of All Things Java. I'm Matt Greencroft.

Richard:I'm Richard Chesterwood.

Matt:And this week, I've been playing with Alexa to try and get her to play this flipping podcast. I hope flipping isn't considered a rude word.

Richard:And he's showing off about it. I spent a good week trying to get it to play the podcast, and had no success, and then you had it for about an hour.

Matt:So, can I now apologise, I've said the word, I'm going to have to say it again, Alexa, a few times, so anyone who's got an Echo will, I imagine, now have it going mad saying all sorts of things, because every time we say that word it wakes up and says things. Even, I've been watching something on TV this week, and my Echo's next to my TV, and it keeps saying the word Alexis, and it kicks in. Its so annoying. Anyway, it turns out if you get the phrasing exactly right, you can play it. You have to say, obviously the opening word, play the latest episode, if you don't say latest, it doesn't do it, I don't know why, of the All Things Java podcast. But, don't say, from Tune In, If you say that it doesn't work either, and yet when it finds it, it says, playing the latest All Things Java episode from Tune In. Go figure. I don't understand, Amazon, but there you go.

Richard:I wonder if there might be some metadata that we have to put into the XML that we put into the podcast to give it clues as to which to play, so-

Matt:Maybe. We'll have a look into that. Anyway, if you're listening to us, whether or not you're on an Amazon device, or a Google device, or any of the other of these smart home devices, thank you for listening, and welcome to this episode.

Richard:So, we're on episode nine now, and we thought, we picked a random topic for this one, which was, I just plucked the UML out of mid air, which isn't ... I mean, we are strictly a ... theoretically, we are a Java podcast.

Matt:JVM podcast, or Java?

Richard:JVM, yeah, of course, full stack JVM. Now, UML is certainly not Java, it's not JVM, but it's related.

Matt:Well, it's something that good programmers, no matter what ... well, we might talk about no matter what language, but certainly good JVM programmers probably should have in their armour. Is that too sweeping a statement?

Richard:I don't know. That's a good place to start. I reckon there'd be a lot of good Java developers who don't use UML. I mean, I don't use ... I'm not saying I'm a Java developer, but I do not use UML on a day to day basis. I don't think you do either.

Matt:No, but then you're not building applications that are solving some kind of business problem on a day to day basis for a third party, where you're not also the business. Certainly where I think you'd expect to see it is where you've got a team of people who are designing a project to solve a particular problem, and they've got to be, I don't want to jump too far into this, into what it is, but it's going to be used in certain environments.

Richard:Right.

Matt:Or I would expect it to be, where you are doing documentation, I guess, in advance of writing code maybe?

Richard:Ah, that will lead to some interesting discussions then. Yeah, I guess, I think you're right. It's something that you probably, if you've got a few year’s experience, you should have it in your armoury, yeah. Did you say armoury? It should be in your tool box.

Matt:I said armour, I think, but anyway.

Richard:Oh well. It's probably something you should have in your tool box, I guess. It's a funny topic, this, because it's fallen off my radar recently. So, we work in different areas now.

Matt:Yes.

Richard:We're not working on great big systems anymore, either of us.

Matt:Actually, that's a really interesting point, because where ... well, we'll get onto, but let's remember this, how does UML, or does UML even have a role, if what you're working on is not great big systems, given the world's moving to the microservice architecture?

Richard:Or even if it is ... yeah, good, that's perfect. So, should we ... let's take a few steps back then, and I guess there's going to be people listening to this who don't know UML, and would like to. So, that should be our starting point. What's UML?

Matt:So, let's talk about, if we can, if you agree, the challenge of communication generally. Right.

Richard:Right.

Matt:Sorry, one of my little topics, I'm sorry. When I started in computer programming in a professional way, working for a bank actually at the time in their IT department, which, I don't want to give my age away, but that would have been back in the ...

Richard:70's?

Matt:... mid to late 90's. There was this role of programmer, and that was my role, and there was this role of analyst, and there were lots of analysts.

Richard:Yes.

Matt:Their job was to interpret what the, what we called business, wanted, what was the business logic that needed to be implemented in code, and act, if you like, as translator between us, the programmer, and the business person who didn't really know what a-

Richard:So, programmers, all working away in some dungeon.

Matt:That's right.

Richard:No windows, all very bad personal hygiene. You wouldn't dare let your programmers speak to the business people.

Matt:Absolutely.

Richard:They talk a completely different language, so you have these intermediaries, the business analysts.

Matt:Exactly, and, you know, the world's moved on since then. I mean, there was a time when you had the analyst programmer, and they decided that one person could do both sides of that job.

Richard:Yes, that was very much in vogue, I think, when we, roughly at the time when we started. When I was applying for my first jobs, it was all analyst programmer, analyst programmer, everywhere you looked.

Matt:Yes, and that's interesting, 'cause working at a bank, it was obviously a lot more traditional, we certainly didn't have that.

Richard:Yes, they were a bit behind that, yeah.

Matt:Yes, and it transitioned into that while I was there, and all of a sudden I became an analyst programmer, because the jobs changed.

Richard:Why is that? Why did things change?

Matt:I think that there was ... The change didn't necessarily solve the problem, but there was certainly this experience of, something goes wrong in that step of communication, meaning that what the programmer thinks they need to do isn't what the business wanted, and therefore what they delivered didn't match the requirement. So you ended up delivering systems that either were riddled with bugs, because they didn't cover what turned out to be regular use cases, but they thought would be edge cases, or not even considered, or even didn't really understand the user experience. They had no concept of usability, that kind of thing. So, the thinking was, if you get the developer closer to the business, and closer to the business problem that you're trying to solve, then you end up hopefully with an application that's more likely to do the job.

Richard:Just out of interest, in this old model, the analyst has gathered requirements with the business. In what form did they communicate with the developers? They just give them a Word document?

Matt:Absolutely. You'd get a, I remember, it was not just a Word document, it was a massive Word document that had to be written in a certain way. So you had headlines that they had to fill in the gaps. They couldn't just freeform write, "This is what the people need," you had to come up ... and bear in mind this was all done with 'project proposals', I'm doing that sort of thing with my fingers to make inverted commas. So, they had to cost up how much time and therefore financial cost to the business it would be to develop this system. The first step would be, they would talk to you as the programmer and say ... sorry, they wouldn't talk to you, apologies, they'd produce a two page Word document that summarised the requirements in such a way as to allow you to cost it up. So you didn't really get the requirements.

Richard:Okay.

Matt:It was all a bit bonkers, but there you go, and then ... sorry, bonkers is one of my favourite words, and then the next step would be, you'd get a 20 page Word document with the project details outlined, of which maybe two pages would be the real requirements. But it never answered the questions you had, so there was no real built in part of that process to go back and ask questions, and clarify, and ... a disaster.

Richard:Yeah, we had, so I was working at defence about the same time, so we had the same thing, but just scaled up, I think. We had a requirements document that was 14 volumes, each of which was very, very thick, and it was just full of ... I can't remember if there were any pictures in at all, there may have been a few diagrams, but generally it was just a great long sequence of, "The system shall ... blah, blah, blah, blah, blah. The system shall ..." Wherever there was a 'the system shall', that was a contractual requirement, because all these had been signed off. So we had to deliver all of those things, and if we didn't deliver them we'd broken the contract. These documents were written years ago. Absolutely bonkers.

Matt:I do remember, I was asked at one point to write, it was a system that was used ... Actually I think we did something like this on one of our case studies, a much more cut down version. It was a system that was used to calculate the average price of a house in different parts of the country, and one of the issues with that is something called seasonal adjustment. So, if you're selling your property, there are times of the year when properties go up in value, and times when they go down in value. No one wants to move on Christmas Day, everyone wants to move in the middle of the summer, it's a general principle. So, they took the sales of houses over the year, and you had to do this process to smooth them out, and so my job was to write the seasonal adjustment process.

Richard:Wow.

Matt:I got this 10 page, I remember it exactly, it was a 10 page requirements document, of which the only bit that was important was a single line, which said, "The system must use the X11 ARIMA calculation." So I went off and looked up, and I managed to get a book on X11 ARIMA, which is the most complicated and in-depth step, it's something like 20 steps of different adjustments and calculations. Now, had they provided me with that, I'd have known what to do. There was one line in this document that was of any use, and it required me to spend weeks learning what X11 ARIMA was. It was horrendous.

Richard:You’d have been bounding out of bed in the morning to get into work, "I can't wait for this."

Matt:Anyway, so, communication has always been a problem, and UML was one of the ... well, I always saw UML as being one of the ways to try and bridge that communication gap between developers and business people.

Richard:Okay.

Matt:Can I talk about birds? That talk-

Richard:Yep.

Matt:Sorry, we're ... birds of the flapping variety. Quite a while ago, Richard and I went to a talk, I think it was in Manchester, one of these Java meet up groups, and a guy gave this talk all about the way people think. What he said was, if you imagine that you're at home in the evening, and you get a knock on your front door, and there's a Martian, and he says, "I've just landed on earth, I'm trying to understand how the earth works, can you explain to me what a bird is?" He said that depending on the way you think, you will answer that question in a different way. So, if you're of the science, technology, mathematical type viewpoint, you'll start saying, "Yes, they have wings, and they have feathers, and they can fly, and they eat insects." What you're doing is you're explaining it, he said, by categorization. You're actually describing the attributes of a bird.

Richard:Okay.

Matt:So you can differentiate between different birds by, for example, what colour are their feathers, what shape is their body, what kind of insects do they eat, and you can use these attributes to define different birds. He said other types of people would say, "Yes," and they'd pull out a picture of a bird, or they'd point up at the sky or a tree and say, "There's one up there."

Richard:So they bring it up by example.

Matt:Exactly, and I think what he was trying to say is that if we now make this relevant, that business people think by example, and techy people think by categorization.

Richard:Okay. I had forgotten everything about that talk.

Matt:All of it? Okay.

Richard:It obviously had a big impression on you, but that makes perfect sense.

Matt:Yeah, at the time it made sense to me, but bear in mind, I'd done a bit of study after my degree about technical communication, so this all sort of, I quite liked his analogy. The idea here is that you're trying to bridge the gap between people that think purely in the idea of how do you categorise, how do you give something attributes, which is the traditional, at least OO programmer would think, and the business person who's thinking in terms of pictures, in terms of customer interaction, a completely different mindset. To me, UML has the ability to help bridge that communication gap.

Richard:Okay.

Matt:So let's maybe talk a bit about the history of UML, where it came from?

Richard:Yeah. It has quite a long ... I mean, there has been a long battle, really. I've not heard a lot about this in the last 10 years, maybe, but from maybe the 1970's onwards, there's been this long battle in software development to come up with some kind of process that we can follow. Some kind of method or system that we can mechanically follow, to take us from an initial idea to a running system that's been delivered to a customer. I think it was referred to as the process wars, where everybody was coming up with their own ... There's a lot of terminology here, but I'm just going to call it a process, so a process for developing software. So, to check any library, there's literally dozens of them in history, like Schlaer-Mellor, and Booch, Booch had his own method, and Objectory was another one. I'm wracking my brains to think of them now.

In my first job we used the Jackson method, which was invented by a guy called Michael Jackson, not the Michael Jackson, but the software engineer. I think that's pretty much what it was like. You had individuals who had a great big idea of, this is how we could develop software, and they'd develop a process. They'd try to make it successful, and you had dozens of these all competing, and it wasn't very satisfactory. So, the UML dates back to the mid 1990's I think? Mid 1990's, and it was an industry effort to pull together all of those competing ideas, and put them all under a single umbrella, and the hope was the entire industry would unify behind this.

It was the Object Management Group that led the effort, which, I don't know how relevant they are today, this Object Management Group. They were the group of people who'd come up with CORBA, which was in the 1990's a very popular, at the time, remoting technology. Completely superseded now by REST and SOAP, and all that kind of stuff. So I don't quite know what gave that committee the right to do this. They obviously just had some powerful industry people on that committee, IBM and those sorts of people. So they put together a proposal, can we get together and come up with a unified way of doing software. That's where it all started, and it led to UML, which isn't actually what I've just been describing, because UML is not a process, it's not a method, it's just a collection of pictures, really. A collection of diagrams.

Matt:I'm not sure we've even said, it stands for Unified Modelling Language.

Richard:Correct.

Matt:So it's a language for modelling systems?

Richard:Yeah. That sort of thing. I mean, language, I'm not even sure what that means, but yeah, it's definitely pictures, a pictorial type language. A language in the sense that there's the symbols, and there's a grammar, so the symbols mean something when you connect them together. I think that's the first thing to say about UML though, I think people expected it to be a unified process, a unified way of building the software, and that turned out to be just far too hard to solve. It's still not a solved problem. We'll talk a bit about that, and what came out of that. There was a unified process that sort of emerged out of it, but the actual successful thing, I think, was the unified modelling language, because really it doesn't say in there how to develop software. It's very object oriented, slanted.

Matt:Yes.

Richard:There's a lot of OO concepts in there, but it certainly doesn't say, this diagram in UML will enable you to gather requirements, for example.

Matt:No, but it's sort of doing the opposite. If you've gathered your requirements, this diagram enables you to document them in a way that hopefully everybody reading the document has the same understanding, and is a comprehensive way of documenting something quite quickly.

Richard:I've got problems with what you said there, but I can't quite process them fast enough, so it might come out in the discussion. I think one of the problems with the UML was that it ... Yes, what you've just described is one of the things that is a by product of UML, it's one of the results of using UML. I don't think that's what they had in mind. I think that's what I have the problem with.

Matt:Okay.

Richard:There wasn't this ... I don't think, anyway. You'd have to talk to the original people on the committee. I think they were looking for a way of, as I say, a way of coming up with a full process, a full end to end process, that at the end of it you'd get generated code.

Matt:Right.

Richard:You know, that kind of thing, and it's like they were being a communication tool. I guess some of the people on the committee thought that, but others on the committee had different ideas.

Matt:Yeah, now you've said that, I can sort of picture that you could be, in theory, creating a diagram, which you then press a button and it spits out-

Richard:Exactly. So, some of the people, there was a method that predated UML called Schlaer-Mellor, which I had a little bit of experience in, and I met the guy, Stephen Mellor, at a conference, and got talking to him a bit, and it was interesting to see what his ... You could see, he had an absolute vision of software development, which is exactly what you've just described. You build a picture, build a model, and let the computer create code from the model. Why do we have programmers sat in that dark dungeon converting the requirements into lines of executable code when you can get a computer to do that. Forgive me if I've misinterpreted his intentions, but that was what I thought at the time, and he was on, I think he fed his ideas into UML as well, so, we'll talk about that. There is an executable UML.

Matt:Oh, okay.

Richard:We'll get onto that a little bit later, but the point of that discussion is, I think UML meant a lot of things to a lot of different people, and it was really up to you as a project to interpret what you wanted to get out of it. If you've got that situation where you've got analysts and developers, and you want to use it as something to bridge the gap, great, fill your boots. Other people saw it as, this is the way we can document our designs, and we'll have a perfect design, and it will match exactly what the code is going to be, and that kind of thing.

Matt:So, I remember, Richard, first even hearing about UML from you, and you at the time were working for a training company, and you had written, effectively, a book about UML, but what was your customer at that time who asked for that course? What were they wanting, why were they wanting it? Do you remember that.

Richard:We did it, I did it with a team of people, and we did it quite organically. We didn't have a specific customer, but we were working for a company, and we hated the way ... We were young and arrogant, by the way, I mean, we were wrong in many cases, because we lacked the experience to understand that we were just ... We thought that the company we were working with was a very big, complex project, and we thought they were doing things all wrong, and we were basically advocating a more Agile approach. It wasn't called Agile then, but that's basically what we were saying.

We were drowned by the complexity in that project, and I think everybody else on the project, bar a few people with brains the sizes of planets, most people were drowning in the complexity of that project, and our argument was, look, we could do this better. What we need to do is, rather than having ... so, they were using a waterfall, that was the fundamental problem, and the waterfall was years and years long. There were people on this project, who had never seen a system run.

Matt:Just because there might be people who are new to development, have only just started, and they're not familiar with waterfall, just as a very basic thread, if there is anyone out there who's wondering, what is waterfall, just to explain waterfall. This was the idea that you start by documenting your project, and you go through various stages of documentation, which are sort of steps down a waterfall, if you like, and then at the bottom, you finish documenting at different levels, you start coding, and you code as you move back up.

The idea is that there is a level of sign off that ... so once you've documented, for example, this is how we're going to test at the very basic level that it works at a unit level, you document all your unit tests, if you like, you do your coding and you check they pass, and then you can move up a level. So, it was a very long process, and it effectively meant that you did all your documentation at different steps, then you started coding, and years later, and months later, by which point what was required has changed, you finally delivered what the original thing wanted. But it was a very long process, and very bureaucratic as well, I would say.

Richard:Yeah. It doesn't work.

Matt:But up until a few years ago, this was the accepted way of delivering big projects.

Richard:I think it probably still is. It's still ... That was one thing we lack in this industry, is we don't have statistics and figures. I can't go to a website and say, well, 43% of projects still use waterfall, it doesn't exist, but my sense is, it is still endemic, and you even get projects ... “We like Agile”, “we do Agile”. “We're Agile here”, if you ask a few questions you'll find out that they’re doing waterfall, really.

Matt:Yeah, okay.

Richard:It's a two year waterfall, it's not that big. So, yeah, waterfall is a disaster, because, you touched on it there, that it's an idea where people have lots of production lines in factories, you know, if you're manufacturing a product, you have a long production line, at the start of the production line go in the raw products, the raw materials, and at the end you've got a complex car, or whatever. People in software have looked at that and thought, well, why can't we do that in software? Your raw material's the requirements going in at the start of the production line, and at the end of the production line, out pops perfect working software. From a management point of view, we must be able to do that in software, and that's kind of where the waterfall thinking is.

So, at the start, as you said, you do all the requirements first. The reasoning was, if you just start coding, if you just start hacking away, you're going to end up with a load of spaghetti code that doesn't do what the customer wants it to do. So we'll put the brakes on, we'll just focus on the requirements, we'll engineer the requirements until they're perfect, and then sign them off, and only then move to the next stage, which will be doing the design. Exactly what you said there, so I'm just reiterating, but I'm reiterating just because it sounds, you know, anyone would buy into that if I was selling that to a manager. Anyone with a brain would go, yeah, great.

Matt:And you can sell it, because you've got clear tick off points at every point, so you can say, we've achieved this milestone. So project managers love it, financial controllers love it, it fits.

Richard:It’ll fit on a spreadsheet

Matt:Yeah.

Richard:A nice Gant chart. Microsoft project.

Matt:Absolutely. Absolutely.

Richard:The problem is, it doesn't work. It doesn't work because software isn't ... It's the 'soft' in software that's the clue. In a software project, you are inventing something new, every time, you're inventing something new. That sounds like a bit of a, I saw your face then go, "Really? Are you really inventing?" Course you are. If you're not, why are you doing it. If this already exists, we'd buy an off the shelf product.

Matt:So, when you said that, my face is doing that because when you talked about a production line, I suddenly thought, was picturing in my head, okay, so, a car. Yes, I can see what you mean there, but when you make a car, you are for most of it buying pre-constructed products and you're assembling together, and actually, software-

Richard:You're turning a handle. That car's already been invented, and designed, and pre-tested before you run the production line. That's the key missing piece.

Matt:Yes, and software, yes, you're not doing that. You're having to come up with, every single project is not using, you know, you're not simply taking classes from other frameworks and putting them together with no glue, you're inventing the glue, and that might be ... well, it is, the vast majority of the work. Yeah, absolutely.

Richard:So what happens in practise with the waterfall, let's say you've given yourself, say it's a very big project, we've got two years of requirements and analysis. Well, you are, I guarantee you're going to reach that milestone on time. I'll guarantee it, you're not going to slip, How can you slip, because when you get to that deadline, you'll just sign the document off as done. Right, we understand the requirements. We've done two years, we must have got it right. Then you move on to the next stage, and only then you realise all of your misunderstandings, all of the things you just didn't even know about, and the requirements document's suddenly come out later on.

Matt:All ... of course, by the time you start coding, those requirements have changed, because the world's moved on, and that happens so often.

Richard:Absolutely, and this is why massive government projects in particular are often not delivered at all.

Matt:Yes.

Richard:That cost 20 billion pounds. I'm not thinking about a specific project there, 20 billion pounds. 20 billion pounds of taxpayers money. So, that was the water ... I can't remember what got us into the waterfall. Oh, you asked me what, how did I get into UML's, I think?

Matt:Yes, yes.

Richard:So we wanted to get this company Agile, so we started writing material, and that turned into a training course, ultimately, which that business did take on board, and a few projects around that business used that course, and got themselves up and running. Then eventually we all left, and just took that course with us, and it founded a training business. It became a course called UML Applied, and we couldn't sell it fast enough. I mean, everybody ... it was just easy to sell. We didn't have Facebook then, but we didn't need to advertise it. We were constantly busy going around the country doing UML training, it was ... it's hard to get across now, this is mid 2000's, just how hot UML was.

Matt:Which is interesting, because ... I remember saying, when I first came across it, which was you, I remember you telling me about it, and then you gave me a copy of this book, sorry, this training manual, the book that you'd written, and I remember creating, it must have been a use case diagram, I guess, in a document I was writing at the time for my work. I think by this time I was an analyst programmer, so I was expected to do the two things, and what became obvious to me was that you could, with no knowledge of UML, you could look at a picture and get a sense of what it meant. So actually, it was a fantastic way to say to the business, "This is how I understand what your requirements are," and the business, with no knowledge of UML, could look at it and say, "Yes, I get that. That's right."

Richard:Or more likely they'd say, "You've got that wrong, you’ve misunderstood that."

Matt:Which is even more valuable, obviously, to know, so yes.

Richard:Yes. But, I think the problem I had working with UML was, I was usually training developers rather than analysts, and they would want to, "Oh, so how is this diagram specified?" They wanted to know all the little nuts and bolts of every little symbol, and every little arrow and diamond that you could put on in UML. UML was very heavily over specified, I think. If you actually look in the spec of UML, it's full of stuff, and then when you get to the tools that implement UML, they haven't got half the things that are in the spec, so you end up using a kind of a sub set of UML really, in practise. But often, those developers that I was training would want to know everything that's in the spec, and you know, I'm not going to read the UML scope, it's the geeks who read the UML spec. It's madness.

Matt:You've mentioned the tools that implement UML, am I detecting there might be a little bit of a rant coming on here? Because I know you have strong feelings about some of those tools, at least at one point.

Richard:Do I? I'm not ...

Matt:Unless-

Richard:You're leading, really. You want a rant on every podcast, don't you?

Matt:Well, it's one of your trademarks, I think, isn't it, to have a rant?

Richard:I don't think I have a particular ... so, one of the, I think it turned out to be one of the problems with UML, was that it was heavily dominated by one vendor. So yes, the Object Management Group was supposed to be a committee of lots of different players, but one company in particular saw quite an opportunity to dominate discussion, and they did. They did a great job of it, actually. The company was Rational, who had quite a long history of ... I think Grady Booch was one of the founders of Rational, or was certainly like employee number three, or something, and by this time he was their chief scientist. That's what I want to be, a chief scientist, sounds like a great job, doesn't it? I just imagine you do nothing all day, and just turn up to conferences and... That's what I want. I'm angling for a promotion, Matt.

Matt:We need to get you a big whiteboard for your office if you're chief scientist, and you need to be able to write difficult mathematical formulae on it, I think.

Richard:Oh, definitely. So, Rational had got Grady Booch, and they went and recruited two other people who had two of the biggest competing ... So Booch had his own method, called Booch, and there was another guy called Ivar Jacobsen who had invented use cases, and had built a method around use cases. I think he was based in Sweden, and that had gotten a lot of traction in Sweden. I think he worked for Ericsson, possibly, and their software had been credited with really making the company a massive success. There was the other guy, Jim Rumbaugh, I think, who had the, was it the OMT technique? I don't know, it doesn't really matter, but they went and recruited those two guys. So having those three people, suddenly Rational seems the industry thought leader of the time.

A lot of people actually thought Rational invented UML, I don't think they really did, but they were the most powerful, and of course, what's in it for them is, they sold tools. So, they had a tool called Rational Rose, which at the time would have been the leading, we called them CASE tools, didn't we? I'd almost forgotten. Computer aided software engineering tools. So the idea was you had a tool like a CAD tool in engineering, where you sat and drew picture all day, and it could even generate code from those pictures. I don't know what you're expecting me to be ranting about?

Matt:I'm sure I remember you ranting once about Rational Rose and something. Anyway ...

Richard:Oh, well, I would have had a rant there, certainly. That software was of its time, definitely. It was very expensive, but then, you know, its professional software for professional developers, so a few grand for a piece of software's not actually that much, is it? Depends where you're coming from. Anyway, I moved on to a tool called Enterprise Architect, from a company called Sparx Systems, we'll put a link in the show notes, I think they're still going, and they did a great job, because they had a much better price point if you're a contractor or something, and you want your own copy of some software. They were great for that, but actually, their software was, I think, a lot better than the incumbent, Rational. They did a lovely job. So, quite a lot of those CASE tools, and there's an open source one, which I think was called ArgoUML, and that may have moved on since I last looked, but, no, I'm sorry, there's no rant there. There's nothing.

Matt:Oh, okay. Never mind. Shall we talk a bit about UML today, in today's development environment?

Richard:We could try. We're going to struggle here, and my story is that I was ... I mean, I've sort of implied that I was quite a massive advocate for UML, and then something happened, and I can't explain it. It was about 2007, so about 10 years ago now. I lost interest in it. I realised that I wasn't using it on a day to day basis, and I also realised that I had a problem with some of the companies that I was working with who wanted to adopt UML, and I realised they were not using it for the purposes you described. The business analysis part I love. If you've got a problem, you don't know a domain, and you're in complete virgin territory, and you don't understand the scope of the problem, all that kind of thing, I think UML even today is a great tool for doing things.

Build a use case diagram, a domain model, state charts I'm a huge fan of. We should do a course on this. We haven't quite worked out a good format to do it, and I think it would look dated, because I don't see many people talking about UML now. But I'd still, you know, I would absolutely do that today if we're in that situation. Then, once you've got that understanding, and you start developing the software, this is where I have a problem. I think most people still think of UML as being a design tool. It's about capturing designs, and many of the projects I was working with were asking me, "Come and get us started on UML, we want to use it to specify our designs," and I hated that. I don't think it works, and I was often getting the blame for things going wrong.

Matt:What do you mean by 'specify our designs'?

Richard:So, I think this goes back to ... and this is why I think this way of thinking is dated. So, go back to the 1960's, when you're coding in assembler or something, and obviously, you look at assembly language, it's incomprehensible, unless you've got a brain like a computer. Assembly, incomprehensible. So, what do you have to do? Obviously, you've got to put loads of comments in assembly code.

Matt:Yeah.

Richard:By the way, can I digress for a second? This is just lovely, I found, just, I was browsing two days ago, I found a complete disassembly of Super Mario Bros. on N64, so if anybody's listening to this who hasn't ... has heard about assembly, and doesn't really know what it's about and what it looked like, we'll put a link in the show notes. The complete disassembly of Super Mario Bros., so, you know, a big hit game. A genre defining game, and it's been completely disassembled, and somebody has sat down, over years I assume, and commented every single line of that assembly. We're talking hundreds of thousands of lines of assembly code.

So, you'll have a line that will say something like LDA,4. That's the code, and the comment alongside will say something like, "Initialise the number of stars available on this screen." I mean, how does it even know ... you couldn't know that just by looking at LDA,4. The comment’s needed. Without that, it would be totally unmaintainable code. So, I'll get back on point now. That's just an example of what code looked like in the 60's, but even, we get quite close to the modern age, languages were not very expressive, and they look like computer code. So you needed to make things understandable and maintainable. You needed a level of abstraction on top of that.

So projects needed, right, we'll do a design, we'll do a picture, which reflects what we're going to be coding up. Then, when you code it, we want to be able to go back to this, and we want to be able to look at that code in four years time and understand it, and to do that, we'll make sure that the diagram that we've drawn matches that code. We'll keep the two in sync. That was the idea. So, as I say, if you're working in assembly, or C, or something like that, you can see the value of that. Its basically like having a comment, a graphical comment, and I found myself working with projects who, even today ... I don't mean today, I'm going back about 10 years, who were working on Java, and they were insisting that they needed that, and I just came to realise that was total fool's gold.

Matt:It's interesting, because as you were saying it, I was thinking, in today's world if you were starting a project today in Java, first of all, obviously, if you're using test driven development, you're determining what attributes a particular domain object needs on the fly, as you go, to meet the business requirement, not the other way around. UML is exactly working the other way round.

Richard:Absolutely, so if you're working on a Java project on day one, you should be able to say, "Show me the tests, and that will give me a like user guide to what's going on."

Matt:Yes.

Richard:Now, I know it's not quite as beautiful as that, that's the-

Matt:But it's interesting that when we write code, we're relying really on names of variables, names of methods, tests, and very occasionally, you'll put a comment in. I mean, I tend to put a comment in when you've got, like, an IF statement to say this is unusual, you don't expect this else, and this is what it really means when you've got the else, because the else doesn't make sense.

Richard:And you can always refactor, wherever there's a comment, that's a refactor.

Matt:That's true, a refactor.

Richard:You know, a new method, or something like that. Yeah, it's not needed. So, there'll be a lot of people, there'll be a lot of project managers, I can hear them now, and I can see them, I spoke to them at the time, they would say, "Yeah, but, there's always places where Java code's not readable, so I want a design. A pictorial design will speak a lot more than the code can possibly speak." What they're doing there is, they're picking holes in it. You can't ... your Java's never going to be perfect enough to be, it's not going to read like English. You are going to need some experience of Java, and your unit tests, they're not user manuals. An average person can't just look at unit tests and get everything, but I think they're a damn sight better than the pictures. Even if the pictures were perfect, you've got this killer problem, which is keeping the code and the design in sync. It's impossible. I don't care what any tool vendor ... Now I'm ranting.

Matt:Good, good.

Richard:So, the idea was, oh, that's a solved problem. So a salesman from Rational, circa 2002, would say that's a solved problem. You do your design in Rational Rose, and then you press a button, and it will blow out code skeletons for you. So then you generate Java, public class with the curly brackets will put the methods in for you. You then go and make changes to the code, and now here's the magic. It was all called round trip engineering, here's the magic, you press a button on the tool and it will modify the diagram, so the two are kept in sync. Yeah. Problem solved. Of course, it's not problem solved, because it doesn't work. The picture, you can't generate the picture from code. The diagram ends up looking messy. You've got to remember to press the button, and, I'm sure there's somebody out there listening who's solved that problem, and think it's not a problem, but, I….

Matt:You know, is this not trying to solve the wrong problem? Because what they're trying to do there, and you said this earlier, is they're trying to automate the boilerplate code writing part of the code, and actually that's not the valuable part of what programmers do. So, it's taking away the ... if they could find a way to do the more complex stuff, that would add real value. Finding a way to automate the really basic stuff that takes not that much time out of your day anyway is solving a problem that….

Richard:That’s given me the chance to throw in, and it really is, I can't put any meat on the bones here, but there was, again, it was circa 2006 here, there was a movement towards what they called executable UML. It's the sort of thing Stephen Mellor, with Schlaer-Mellor, had previously been trying to do, is that you wouldn't have code anymore, you would just have the model, and their buzz phrase was, the code is the model. So you would do your pictures, and then you would press a button, and you would generate code that you don't have to see. That's the crucial bit, so you wouldn't have to modify it. Now, that exists. It's still out there. Model driven architecture is the overarching term for it. It does exist, and it's out there, and I'm sure there are projects who've made it work.

Matt:So, this is probably along those lines then. I do remember working with some people who were using a system they had purchased, and they were not programmers, they were mathematicians, and this was a statistical modelling system. So the idea was, they wanted to run a series of statistical models one after the other, where they could say, here's the parameters to, for example, a particular statistical distribution. I apologise to the people listening who've not got that mathematical background and don't quite know what I'm talking about here, but they, what the system did really was draw a flowchart where you say, here's your input data, flow through to this step, and it could draw different flowcharts for different parameters in. They effectively, yes, you could see behind the scenes, that programmatic system was obviously generating some kind of code it could then run. They were not interested in code, and it allowed non-coders to do this kind of stuff in a very specific domain.

Richard:So, working in specific domains.

Matt:Yes.

Richard:That's the important thing, and I think the idea with something like executable UML is, yes, you have to, as a project company or whatever, you build the generator for your domains. I never got into it, to be honest, so I have no knowledge of it. So, I made a decision about 2008 that I was much more interested in Agile, and that's what got me into the whole thing, and I saw UML being used in such a non-Agile way that I kind of washed my hands of it. I've now bought into, one of the things Agile says is, favour code over documentation. It doesn't say we're not going to do documentation, but it says the code is the thing you're delivering, and that should be the thing that you put your care and attention into. So I quietly abandoned UML, and I don't generally use it.

Matt:Do you think there's any particular instance now where you would want to use UML?

Richard:Yes, I said, you give me a brand new problem, and I don't know anything about it, and I've got to talk to somebody who does know about it, UML's perfect.

Matt:Right.

Richard:The use cases, state charts, a domain class diagram. Not a detailed class diagram, but a domain class diagram works beautifully.

Matt:So, you've just explained that is what I think of as a very OO way. So, the concept of domain class is, state is a very OO concept. If you were doing functional programming, you know, is there a role for UML in functional programming?

Richard:Yeah, definitely. I don't think what I've described there is object oriented, it's just that I'm using models like ... So, I've mentioned the domain class diagram there, which is a UML class diagram, and for listeners who've not used UML, but you probably know about Java classes, so, it's a way of capturing classes. But I'm not thinking on those terms at all, I'm thinking in the real world. I'm thinking like the guy you were talking about previously, some people, developers like myself, think in terms of classification of things, not object oriented in any technical sense, but it's just that I'm working in a domain that I don't understand, whatever it is ... give me an example.

Matt:Manufacture of sweets, candies for our American listeners.

Richard:Manufacture of sweets. Don't know the first thing about that, but there's going to be classes of objects in that. In the terms that people use, in other words. I'm just building a dictionary really with that diagram. So, the business people I talk to are going to be using terms like ... oh, what a bad example, because I can't think of any jargon terms that they-

Matt:Well, different types of sugar, for example, that might go into your candies.

Richard:Beautiful, so we've got sucrose, and fructose, and all those sorts of things.

Matt:Yes. Corn syrup.

Richard:Yeah. I don't understand any of that, but I can classify it, and I can capture it in a picture. Now, you know and I know that if we're doing an object oriented design from that, then that may well inform the ultimate design. Might do.

Matt:Right.

Richard:Actually, one of the founders of, one of the early proponents of object orientation is sometimes credited as the inventor, so, that wasn't ... he had no ... It's a complete misinterpretation to think that OO is about modelling in the real world, so that's something to think about. I'm not really saying that, I just think, even if you're doing functional design, or you implement it in assembly language, I don't care about any of that. Before you start implementing, you've got to have some level of understanding of what the jargon terms are, and I'm just saying that's a picture that will allow you to capture some of those jargon terms. No objects involved, really. And state, that's just a real world concept. I'm not talking about mutable state inside a computer, I'm just saying that things in the real world change over time.

Matt:So you're separating that completely, UML, from being something that aids you to create code, to something that aids you to understand a business problem.

Richard:Exactly.

Matt:Which is interesting, and actually, that's changed my thinking then, because certainly I came into this conversation, knowing we were going to talk about UML today, very much with that view that it's a way of allowing you to design an object oriented system. Actually, I did a quick search online to say what's the use of UML in a functional system, and found a very interesting stack overflow post, where they said, "No, functional programming has a different modelling language, it's called mathematics." I thought that was quite a ...

Richard:Ooh, ouch!

Matt:Yes. I mean, it was obviously done as a rather sarcastic, but it had the most votes. Yeah, interesting as a thing, but ... So, for a modern developer actually, the reason why you need to, or you should at least have a general overview of UML, is because it's a useful way of capturing a business requirement, and having that level of understanding of the business requirement before you start.

Richard:Yes.

Matt:But actually, of course, if you're going to be doing test driven development, you're going to be growing that business requirement over time.

Richard:Exactly, yeah.

Matt:Okay.

Richard:So, the models that I would build sort of become ... I mean, they're useful documents. But favouring the code over documentation, as you'd said, and those documents, you can almost throw them in the bin once we understand things. You wouldn't really throw them in the bin, you'd keep them for new joiners and you'd certainly revisit the models when some major shift in that industry happens and so on, but that's the way I would go. That's why, day to day, we don't really use it, because we're not currently involved with going into brand new projects where we don't understand the domain.

Matt:So, looking at where we have done that kind of work, and I'm thinking particularly, to when the European Union bought in a whole new set of complex VAT rules, and we had to come up with, how do we implement those rules within our business requirements, and our logic. Even now, if we have a change, if one of those rules changes, and we need to go and change our code, we would go back to that original documentation, some of which is possibly UML. I don't think a lot of it was, but there is still that need for that documentation, because it was about, we've got to remind ourselves what the original requirements were.

Richard:I'd say probably, just a guess, but probably the unit tests were built for that.

Matt:That's true, yes.

Richard:Arguably more descriptive than the diagrams would be, but that's just an example. Yeah, absolutely, they could be.

Matt:Yeah. What the unit tests don't give though necessarily is the flow. Because they're testing units of calculation, they're not giving you that logical flow, and of course, if you can remember, we wrote it knowing it was going to flow in a particular way. Actually, if it's that flow is changing, that's the bit the documentation-

Richard:Yeah, so UML gives you about 14 diagrams, I can't remember the exact number, and I would recommend that any developer ... I mean, the one you just mentioned, that flow, there is a diagram called the activity diagram, it's just a flow chart. We've called them flow charts from the '60's or whatever, and anybody walking off the street could understand a flow chart, there's no need to go on a training course to learn about that. That's what you'll find most of UML is, you don't really need a train- ... If anybody who has been on my UML training course in the 2000's are sending in for a refund, sadly, the money's been spent, so you can't.

Matt:Well, in those days you probably charged tuppence ha'penny, didn't you? So ...

Richard:Well actually, no, to be fair, most of that UML training course wasn't about that, it was about how you pull it all together, and what kind of process should you use here. So, what we've just described there, understanding the upfront requirements, and then going and concentrating on the code, all that was in the course. It was valuable, but the diagrams themselves you could pick you in no time. We often, on our training courses, we'd put a caption up, and we're using UML, and we often don't even bother to say, this is ... because people will just infer, so the microservices course, for example, the picture on that course is an overall architecture of how all the components fit together. It's quite complicated, but they don't know it's not even worth…

Matt:No, and actually, I think we've said that, is that one of the nice things about UML is you don't need to know it to have a reasonable ... you can look at a picture and have a pretty good understanding without any UML knowledge, and I think that's one of its strengths.

Richard:Well, you could very easily draw a UML picture, and get the arrows the wrong way round, for example, when you're drawing it, and to somebody who knows UML, that would give them completely the wrong idea, so it is actually worth doing a bit of studying. I think on one of the courses I remember saying, "Do you know what, I'm not sure about that arrow. It possibly should be the other way around." I can't remember which course. Probably microservices deployment. I was actually reading a design document just yesterday, because I'm working on a Reactive training course at the minute, which might not happen, we don't have to talk about that if you want, but it's certainly going to be delayed I think, but I was reading a design document where they were explaining how, on the old model, if you send the request to a server it's blocking, so you've got to wait for a response to come back, and they've used the UML sequence diagram to show this, and there's a bit of syntax on the sequence diagram, which shows basically wait times.

It's pompously in UML called the focus of control, but it shows when you're blocked. Whoever drew this diagram was trying to explain about blocking, they'd got the syntax totally wrong, and they were basically showing it totally asynchronous. It needed ... I spent a good half hour looking at it, and squinting at it, and then realised, yeah, they've just banged that into a CASE tool, something like Enterprise Architect, I think they've used, and that will just make guesses of where these blocks are, and they probably didn't even realise what that block meant. Because I can read that diagram, I got completely the wrong idea from it. I suppose after ... I've been a bit laissez faire all the way through this, "You don't really need to learn it," I'm sorry, you probably do need to.

Matt:Oh, well. Okay.

Richard:Should we do a course on it. That's a ... we've had it, quite a few, over the years, people saying are you going to do a UML course?

Matt:Do you know, it's a challenging one, because it would be very different from the other kind of courses we do, in that it would need to be a lot more pictorial based. I know you're quite keen to try and have the ability to be able to draw things on camera, which I'm less keen on, but you're more of an artist than me.

Richard:Not at all. Not at all, but I think freehand drawing, because a lot of our competitors are ... because we have competitors, you know.

Matt:We do, yes.

Richard:They're all rubbish.

Matt:Well, yeah, absolutely.

Richard:But they exist, and I do find that it's a very common thing now for them to draw straight on, and it always looks bad. Really bad. I think with just a little bit of extra work, it would just look more organic, it would look more natural, and it would probably be quicker than the animations that we do, which are a bit clunky, but they take a heck of a long time.

Matt:They do. Okay, let's have that one ... let's think about that. I mean, I think it's, you know, maybe a short course on the essentials of UML that ...

Richard:I think it might be the one that we keep circling around this week, but anyway, I think it might be the one where we actually record in vision. I can see the room that we're in now, I could imagine having a camera there, and the developers arguing over a diagram or whatever.

Matt:Yes. Might be a joint effort, that one.

Richard:I think that might be the way we have to go.

Matt:We'll have to think about that. Okay, but shall we talk about, you mentioned Reactive might be delayed, or not happening?

Richard:Yeah, it's a ... Reactive's a difficult area, because it's a bit like the Wild West at the minute, and it's a changing area. I'm not really getting very far with it right now. I think, as of today my thinking is, I'm going to build a course showing what Spring 5 support for Reactive is.

Matt:Okay.

Richard:They've got their own interpretation of Reactive, and I think that will do for now. We need to do far more than we do on concurrency, and that kind of thing, and at least it's a toe in the water. I'm finding a lot of the frameworks can be very, they're very mathematical, and I want to get a practical, you know, a real good working example, and I'm behind on it. But I think you're doing well on your course?

Matt:So, I'm on module two of Java web development, and it's probably about halfway recorded now. I've made a decision ... Actually, it's probably more than halfway, all I've got left to do is three chapters, which are covering Ajax, web services, and asynchronous servlets, it might be four chapters, but I've decided, originally I was thinking that I would put a couple of chapters on the end covering the Java 9 part of web development. So, that is the Java 9 way of doing websockets, and possibly something about the new HttpClient class, which is more about consuming a website than building one. I've actually decided I'm not gonna do that. I'm gonna stop module two before those. There may in the future be a module three that covers the Java 9 bits.

I don't want to do it now for two reasons. One is that I don't know it, so it's going to delay things, and I have to learn it, but also, I am using Java 8, and I don't want to upgrade to Java 9, let me be honest, just yet. I think there's too many things I'm supporting, too many things I'm doing in Java 8. I want to leave it a few months first. So, if you want Java 9 stuff on that side, please shout out, please do tell us, but, I'm not saying it will never happen, but I'm not going to do it just yet. So, I'm going to stop module two where we originally planned to stop it, actually, which means I would hope, I know on the website it says due late November, I think. Absolutely we should be on tract for that. I then ... I then guess we're looking at, I keep promising this, we need to do something on JSF.

Richard:Oh. Oh, ugh, oh.

Matt:I've had a couple more people asking, but it's ... I only say it to get that reaction from you Richard, but, maximum of a couple of hours, just to get you started on JSF, and then we can close that one off.

Richard:Oh, oh.

Matt:I think Spark, hopefully, might be next.

Richard:It will, yeah. But ... JSF, can't we just bin it? We've got material on JSF. If people ask for it, we could take it off the site, and if people ask for it, give them that under the table. We need to be, as a company, we need to be clear about what we like, and what we dislike. People want guidance from us. I know there's two models, basically. Some customers are, "Look, my project's using this, and I want you to show me it. I don't care whether it's good or bad, my project's using it," but there are a lot of them saying, "Well, what should we be learning, and what should we ..."

I don't want ... what I did, I was forced to write a JSF course, back in the, about the same time as I’ve been talking about on this video, by an investment bank, and I said to them at the time, "Look, I really don't like the look of JSF," but they insisted, and they twisted my arm. They said, "You've trained here before, we like what you do, so come in and do it regardless." "Okay, well, if you're going to pay me, I'll do it." So I did it, and then something like three years later they booked me again for a Java course.

I went in, and I bumped into one of the people in the JSF course, and they said, "Oh, right, you're the guy that told us to use JSF, aren't you? We abandoned it, it cost us a fortune, and your name's not very ...," and he was serious. It was obviously a different project in that company who booked me for the Java course, and it had blackened my name. I didn't recommend it, but you're the front person for it, so you're going to be the one that gets the flak, and I don't want people saying, "Oh, you think JSF's good, don't you."

Matt:So, I would be delighted not to do a JSF course. I wonder about extracting the JSF chapters from the old course, sticking them on as a module with a very clear message that says, and maybe even an introductory video that says, "We've had a few people ask for this. We did this a long time ago, and we're not going to redo it, because there's too few people asking for it, but if it's useful for you, here it is."

Richard:Yeah. That sounds possible.

Matt:Just getting it back on with no editing, just the old version, because it's interesting that where we have had people ask for it, that's what we're doing. We're saying to them, "Look, we did have this old course, we'll give you a copy," and actually, they never come back and ask questions, so maybe it's satisfying that need. So let's have a think about that, but that might…

Richard:There is a slight problem with it, in that, that JSF that we did, although I don't like JSF, if we're going to do it, we're going to do a good job of it, and unfortunately that JSF was part of a bigger course, so, we could get away with just doing two or three chapters, and then saying that's enough, we'll move on to something else. It was just to get your feet wet, and actually, I think, since there's been newer versions of JSF, there are better ways to do what we're doing on that. So it's kind of like old fashioned JSF that we've got in there, and again, I don't want to look like we're ... so we've got a problem there.

Matt:I'm very persuadable to not do a JSF course, I'll be honest with you. It doesn't excite me.

Richard:Well, let's park it, at least.

Matt:Okay.

Richard:You know, Spark is something that people are really demanding, and we need, because without that, that's kind of like the gateway into highly concurrent streaming, all that sort of thing.

Matt:Yes.

Richard:That we've not got enough of, and I'm trying to get in there with Reactive, and it's all I've got. If there was already a Spark course, it'd be a lot easier to then build some momentum a bit quicker.

Matt:Okay, well, look, let's agree then that as soon as I finish web development, I'll start on Spark.

Richard:But we'll work on that together, won't we?

Matt:Working on it together, absolutely, because yes, it may be that you'll record that. We worked on the big, the no SQL course together, and I think you recorded it, and it worked quite nicely as a team, so we'll have a think about that, but I'll certainly start looking into Spark, then, as my next project.

Richard:The big question there is, though, do we do Spark using Java, or do we use Scala? Which is ... whew, yeah.

Matt:What's your sense of a, “here's enough Scala to be able to start doing a Spark course” in Scala?

Richard:Oh, any Java developer with reasonable ... you know, if you just learned Java last week then you're going to find it difficult, but if you've got some reasonable experience, we're not going to do any hard Scala. It will be classes, and ...

Matt:Because I think that there's a ... actually, Scala's one of those things that even though you might not need it for your job, or want to get a job in Scala, if you have a basic understanding of Scala, it can elevate you a level as a programmer. So an introduction to Scala course, here's a ... Getting started with Scala would be something that I think would be very popular, and I know we talked about doing something similar with Clojure and we've never got there, but just as a-

Richard:That would be a vanity project, but Scala would be…

Matt:Scala's definitely, yeah.

Richard:A little bit less relevant now, because ... so, if you look at any of the Reactive code, you've got, using the library, like RX Java, which is one of the libraries that we might put in the Reactive course. You know, it comes from Netflix and other people. There's basically two ways of working in it. You can use the Java 7, and earlier approach, which is you've got to work with anonymous in the classes, and you basically have like, 13, 14 lines of code, and it looks absolutely horrible, and it isn't readable, but if you're using Java 8, then you can use lambda's, everything turns into nice single lines of code. Now, that would be my reason for using Scala, so in all of the Spark code I've seen, you look at Spark Java and it just looks horrible, so you look at Scala and it's all one lines. What I'm not, forgive me, I should know this, but I'm sure you can use Spark functionally using Java 8, in which case there'd be less of a burning need, possibly, for Scala.

Matt:Well lets look into that as part of working out how we're going to do the course. I think we're running out of time, so ...

Richard:Great stuff, that's all coming soon. So, a funny topic, that UML, in that it's something that we've kind of semi abandoned in our professional career, and I think the industry in a way, we've astudiously, is that a word, we've very carefully avoided mentioning much about Agile on this podcast, because we want to do another podcast where we just talk about Agile, so that will come in the future. Quite possible not the next one, but we want it quite soon. That's really, I think, the summary of this discussion, is we're far more into Agile these days, although we don't follow any prescriptive, we don't do anything like Scrum.

Matt:No, no.

Richard:So, we could do with an expert coming into the podcast to talk about things like Scrum.

Matt:We might try

Richard:Yeah, and basically, project management with Agile is a whole topic, but as a developer, Agile is not complicated, and it shouldn't be complicated.

Matt:No.

Richard:We'll have a separate podcast about that.

Matt:Good.

Richard:We tried to make it two weeks ago. I think it's been three weeks since the last one, but-

Matt:Yes, we'll do it when we can.

Richard:Just imagine all these tens of thousands of people sat next to their Echo Dots, constantly saying, "Play the latest podcast," and their disappointed little broken hearts that there isn't a new one.

Matt:Well, I know that our marketing team have set up today's podcast as an event on Facebook. I don't know how many people have been watching that event to see when it would come out, but…

Richard:We were really disappointed. We didn't quite break the 10,000 attendees.

Matt:We didn't?

Richard:We didn't.

Matt:Okay.

Richard:So next time we'll make it.

Matt:Next time, we'll hopefully get there, yeah. Anyway, if you've been listening, thank you very much. Comments welcome as always, and hopefully see you in a few weeks at the next one.

Richard:In a few weeks time. Great to talk to you Matt.

Matt:And you.

Richard:See you next time.

Matt:Cheers, bye.

Listen via:


Be notified of new posts