Episode 044 – Scrum Sucks and so does Node

 
In this episode the guys talk about the latest blog post from Ron Jeffries (Developer Should Abandon Agile) and the presentation by Node.js creator Ryan Dahl (10 Things I Regret About Node.js).

Clayton plays the part of the pessimist, John takes the optimistic stance, and Ash remains a realist.

 
https://twitter.com/grales/status/1005600509112266752
 

John Callaway – 00:39 – So guys, what are we talking about today?

Clayton Hunt – 00:39 – Apparently a Scrum Sucks And So Does Node. Yeah.

John Callaway – 00:45 – So this week there were a couple of interesting developments. Ron Jeffries posted something about all developers should be abandoning Agile and Ryan Dahl had a an interesting talk given at JSConf about the problems inherent in node. So Clayton, you had written a series of posts entitled, Scrum Sucks. You want to kind of give us a brief catch up on on those blog posts?

Clayton Hunt – 01:13 – Well, unfortunately I didn’t get around to finishing them, but the basic idea was that the way that that companies, at least the companies that I’ve worked for attempts to implement Scrum is what sucks. Not necessarily Scrum. The framework itself. Typically what I have found is that the developers will kind of lead the charge to do Agile because we’ve heard it’s better or, or we truly believe it to be a superior form of development from the old Waterfall days, but that message never gets heard all the way to the top and at some point it stops and wherever it is that it stops, that’s where the pain starts because the business, whether it’s the owners of the business or the, if we use Waterfall terms like the sponsor of your project or the business analyst or the project manager or maybe your own manager, the development manager or even some other developer on your team doesn’t understand and doesn’t care to understand why we are trying to do something different.

Clayton Hunt – 02:20 – And so they either decide that whatever that thing that you’re suggesting or that was in that book, uh, was suggesting is not really going to work before even trying it. Instead they make up their own process or they merely placate you and they do Waterfall behind your back. But then tell you that we’re all doing Scrum when really that’s not what’s happening. Uh, all of that stuff leads to implementation problems in the framework and, uh, kind of creates a really terrible experience, like worse than the, than the Waterfall experience. If everyone agreed to do Waterfall or traditional development than a, I think it would actually be a better process than the halfway attempted or merely scoffed at versions of Agile that a lot of companies actually end up implementing.

John Callaway – 03:13 – Yeah. Let me read the first line of Ron Jeffries’ post entitled Developers Should Abandon Agile says Agile has become big business.

Clayton Hunt – 03:23 – Yeah, it’s, it’s, um, uh, from, from his point of view, uh, and, and I somewhat agree is that it’s, it’s a certification you get, it’s a sticker you put on your wall. It’s not something you actually do the businesses, they just, they just want to be able to say that they’re doing it. They don’t want to actually do it. They don’t want to adopt the concepts behind Agile. Yeah. I’ve been working on Agile teams for don’t know, eight or 10 years now in some form or fashion. It seems often that the emphasis is more on the policies and procedures and going through the mechanics rather than a, I think the spirit of the Agile manifesto is, is lost in a lot of organizations and that, you know, if we’re, if we’re following these guidelines and we’re doing these tasks and following this set of procedures than we are Agile, which, which, which is, is almost 100% against the, uh, the manifesto, the manifesto talks about how it’s, you know, while while some policies and procedures are valuable, it’s more important that you’re communicating and what ends up happening as communication goes out the window.

Clayton Hunt – 04:35 – And because the practices are loosely defined among most Agile communities, even within Scrum, it’s hard to find a book that says do exactly this and they don’t want to tell you that because it’s supposed to be Agile. You’re supposed to adapt and change based on the needs of your specific situation. So what companies end up doing is they don’t correctly implement a starting strategy. So like, like the Scrum framework as a starting point, not a finishing point, but if you want to learn from it, you have to start, I feel so at least for for a few sprints to be determined by your company or your team or whatever, but you have to start for let’s say three sprints at least and just try your best to do exactly what Scrum says to do and then evaluate whether or not those practices helped and then make small changes in directions that you think will help you more. But they don’t. They don’t do that.

Jon Ash – 05:35 – So I think that what we’re seeing is that the attempt to do what you’re, what you’re saying is the a result we’re getting and what company, what your. What you’re saying is that you adopt some pro practice, some process, some methodology, right, and try to begin there and then improve on it. However, that is already walking away from the spirit of Agile, which is the idea that you’re going to have something over a process, over a methodology over you’re gonna have people. Was it individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. And so the reality is that if we have any sort of framework where we start to saying, okay, well this is just a starting point, or this is. This is a framework itself, while you’re having to adopt that framework on and that all of a sudden by the very nature of what people want already and the reason why we have frameworks is because people want to have something.

Jon Ash – 06:44 – They want to have something that they can follow so they can learn so they can. So they don’t have to think for themselves in a sense. So they don’t have to kind of generate all of that them themselves. And it’s a good thing. And I would argue that. Wouldn’t argue that that is necessarily a bad thing. But I think the reality is the idea of, well, let me just go out here and get a Scrum off the shelf and then we’ll start with something or a start with some of these things. And then we’ll see what works. They quickly fall back into some of the the things that they had been doing and said, well, this doesn’t. This doesn’t work for me because I’m used to thinking about requirements and this other and this other methodologies so this doesn’t work, so I’m beginning to iterate, iterate on it, and I’m already your, well, this doesn’t interfere with us, so let’s have a stand up every single day.

Jon Ash – 07:32 – So because that really doesn’t interfere with what we had and the process that we had before. And so they begin to actually changing the methodology that to fit the way that it works for them. The reality is that you’re not actually taking on the ideology of Agile to the core and saying, let’s see what we can do. How do we change our behavior to match that ideology?

Clayton Hunt – 07:55 – That’s why I would, I would suggest initially a very strict following of process x doesn’t have to be Scrum, whatever, whatever process x is. So it. It goes against what I would say the best Agile practices are, but by strictly following some process that is definitely not your process for let’s say. So I said earlier, I said three sprints. Well, the average sprint is like a two week sprint. That’s what a lot of companies land on and it’s in between the one week and four week suggested sprint different distances.

Clayton Hunt – 08:33 – So I would say if you, if you take two sprints and you do three of them, that’s six weeks. So if you try a process that is draft particularly different from your current process for six weeks, that’s long enough to kind of like snap you out of that. Um, I’m just gonna stop this and fall back into my old habits, uh, and, and to put you in a better frame of mind to actually evaluate whether the thing that you’re doing is working. But in the end it all comes back to doing the evaluation. You know, did this change work? But if you, if you only halfway make the change, then you still cling to those old processes. And so you never really have a chance for your mind to adapt and to change, you know, it’s like the reason why development sucks in general is because people have gotten set into their ways and they don’t understand that you can change.

Clayton Hunt – 09:29 – So like when I’m doing my day to day development, I am constantly looking for the thing that is the most painful and I am then taking some time and I’m trying to figure out how I can make whatever that is less painful. So if it’s the business processes that I directly effect, I will try to affect those in a way that I think will make them less painful. And then I’ll evaluate, you know, what I’ve done after a little while and if it didn’t work then I’ll go back to what I was doing and, or come up with something else that makes it less painful. If it did work, then great. Then I start spreading the news, um, and to do the same thing with my code. Whatever part of my code is being the most painful at the moment, which I actively seek out. I go and I change that code so there’s bidding less painful,

John Callaway – 10:13 – so let me address a couple of those points. A couple of those thoughts, especially given the section heading under Ron Jeffries post about under an imposed approach, I would be cautious about following the the stricter adherence to Scrum or some Agile methodology. If you are in an environment where you can’t do that evaluation and make that change. If you’re in an environment where they say, we are Scrum, we are Agile, we follow three weeks brands. These are the policies and procedures that we follow. These are the meetings that you are scheduled to attend. You must adhere or your will will be broken and so it’s. It’s a dangerous game to play.

John Callaway – 10:57 – I think the initial intent in in some of the outline of this particular writing is more about giving the control back to the developer because the developer knows how to more quickly more effectively do the development of software, but I think a lot of teams and a lot of companies and clients just are nervous about relinquishing that control back to those that may not know how to do the software and I, I say that in air quotes, they may not know how to write the application.

Clayton Hunt – 11:33 – Sure, sure. They do. You put a button here, you put a label there and then when they click the button it takes them to a new page.

John Callaway – 11:41 – Yeah. So I think if we can get back to the, we are professionals and clearly define the expectations and all work towards a goal. Maybe it’s naive to think that way, but you know, at some point we are professionals and the development profession in general is usually pretty fairly compensated. So you would hope that we’re all out there trying to do good by our clients or our customers or companies complete work in a timely fashion.

Clayton Hunt – 12:12 – You would, you would hope that, uh, and, and forgive me if I be mean for a second, but uh, in my experience there are very few individuals, developers, BAs a project managers, anything. There are very few that actually care about improving their current situation. So many developers are more than happy to show up at 9:00, do whatever they’re told, and Goldman five and they don’t care if the thing that they were told to do is super painful. They don’t care if it is costing the company money. They don’t care if it is worthless of development effort that’s not going to go anywhere. They’re just going to do what they’re told and they’re going to collect their paycheck and the same thing goes for BAs and project managers. They just want to show up and collect their paycheck and go home.

John Callaway – 12:57 – As cynical as I am, I’m still optimistic that given the appropriate amount of autonomy,

Clayton Hunt – 13:04 – every company I’ve ever worked at, I have fought to get the people that I work with into that mindset of looking for the thing that is painful to them and improving it, and whenever business requirements come around and we have a discussion about priority, I asked what’s going to deliver the company the most money? What is the what provides the most business value? That’s the thing I want to focus on,

John Callaway – 13:28 – Did you ever think, maybe it’s just you.

Clayton Hunt – 13:30 – I’m sorry. I care too much what,

Jon Ash – 13:33 – Clayton, you may be taking the pessimistic approach here and, and John might be with my argue that John Callaway is taking the, uh, the optimistic approach living. Let me be a realist here. So here’s the question, if we have so many people that don’t care, is that because that is the, is that the cause or is that, is that basically the beginning state or is that a caused state? And I think that it might be a caused state. And I think the big issue here is that companies or especially enterprise companies don’t trust people. They don’t trust their employees in general. And so when you’re talking about having a developer who, in let’s be honest, even especially in enterprise companies in, if they’re an enterprise company, that’s not a technology company than, isn’t.

Jon Ash – 14:31 – This is very, very much the case. You know, they’re, they’re a part of some sort of extraneous it team that’s general, uh, ancillary to the major portion of what the company is doing. And so they are expected to operate in ways that don’t really affect the company and they’re just sort of like the work people that get work done. Right. And we’ll hand you will tell you what we need. We’ll tell you what we do that you’re kind of treated like a, like a construction worker. You don’t, we’re not going to, you’re not going to be designing anything. You’re going to be building out anything. You’re just, we’re just going to give you some materials, we’re going to give you a project manager, we’re going to give you a couple other people that might know what’s, what kind of is going on and then you’re expected to sort of construct the software and there isn’t the idea of in their mind there isn’t the idea of this need for engineering to actually take place.

John Callaway – 15:33 – Yeah. And is that a result of the Waterfall approach to software many years ago in that this, this is the prescription for writing this application here. You software developer implementer, you go implement this thing that we spent weeks and weeks and months planning?

Jon Ash – 15:51 – I think so, yeah. I mean, I think, uh, Uncle Bob talked about, uh, are you talks about like basically the old school engineering methodologies, right? And in the old school like building something a was the expensive part and designing it was the cheap part, right? Whereas here in software it’s the other way around. So a lot of the, the historic kind of design principles and development principles, project management principles, all of those things came out of the physical world, physical engineering, physical design space where it costs a lot to actually produce the product. And so you do all of the design, you do all of the thinking, you push the, the actual production off as far as possible.

Jon Ash – 16:36 – Um, and that’s where the idea of Agile kind of coming, coming in and saying, look, no, we can get the, we can get the production side, uh, close to two requirements, close to the design side and, and close to the, the actual dependency, the real person who’s depending on, on the, the, the product itself.

Jon Ash – 16:57 – Yeah. Except for, except for now, uh, we’ve, uh, for the most part because every company has quote unquote adopted Agile. Um, we ended up with the worst of both worlds. There’s practically no design being done and there was no care in the development effort.

Clayton Hunt – 17:14 – There’s not a lot of iterating on the solutions that are being delivered. Like if now if you deliver a, this is the version one of this working application or this screen or this functionality, if you haven’t had those conversations ahead of time, it can, it can be embarrassing. It can be frustrating to the end user, to the clients that they don’t understand that this can be improved upon. This doesn’t have to be the last deliverable. We can make it better. We want to get feedback and we want to improve it.

Jon Ash – 17:47 – Yeah, if you, if you, um, if you look at that whole iterative development aspect and as a developer, you, you try to do that, you’re like, okay, well we want to get something out. We want to get it working. So I’m going to build this and I know that this isn’t the best way to build this. Right? But it will work for now. And then next sprint we’ll go and we’ll make it better to fit the current needs of the system. Uh, what the company will do is end the project as soon as you get something delivered and then you’ve got code out there that you know, is only good for like four months. And then the next developers that come along, there’ll be contract developers and they’ll see your code and they’ll just roll with it. Whatever terrible patterns you had set up that you had planned to refactor, they will just institute everywhere.

John Callaway – 18:28 – Well, stop writing terrible code.

Jon Ash – 18:32 – So the other, the other issue with the iterative, the idea of an iteration, does it often also gets it interpreted not as an iteration but as a like stage or a like a gate, right? So like you, you might, you might say, well we’re going to deliver this in multiple stages. And so this iteration we were bringing these features, but those have to be complete features. Right? Effectively when they get delivered in that iteration, there’s no. Coming back to those features, there’s no like, let’s improve this work. It isn’t, it isn’t a question of we’re always delivering the whole system and we’re trying to get to the most, the minimal viable product right from the first time we’re, we’re, we’re, we’re just simply going, okay, well we’re going to build this section of the complete solution that we’re going to. We’re not gonna release it until we get to stage 14.

Jon Ash – 19:26 – We might not agent, but what are they going to be split up and we call that an iteration, but it’s not an iteration at all. It’s just long scoping.

Clayton Hunt – 19:35 – Yeah, I’ve, I’ve had, I’ve had 20 sprints add up to a single deployment, so really it’s just Waterfall two weeks at a time,

Jon Ash – 19:35 – right? Yep.

Clayton Hunt – 19:42 – Which is not. That doesn’t help anything. It doesn’t do anything. It doesn’t accomplish anything. You’re not getting the product out faster. You’re not reducing the time to market so that the company could start making money off of the stuff that you’ve already developed. I’ve had a, I’ve had an MVP point one. It’s the MVP, but we’re not a. we’re not actually going to release it because it’s not. It’s not good enough. So we’re just gonna call that point one and then we’ll release the real MVP later.

John Callaway – 20:10 – Wait, what does the V stand for?

Clayton Hunt – 20:11 – Then? It’s a most valueless product.

John Callaway – 20:16 – Babied like that’s, that’s the kind of. That’s the kind of stuff that the companies are doing.

Clayton Hunt – 20:19 – And how do you, how do you get an entire industry to understand the concept behind something when it’s. When it’s a very. Yeah, there’s the, there’s the manifesto for Agile software development and it’s great, but the first time you read it, it’s just words on a piece of paper or a website. You have to, you have to analyze it, you have to understand it, you have to take it into you before it I worth anything. You know, it’s not, it’s not worth anything until, until the company buys in. So how do you, how do you get those, those thoughts and the and the that mind, that mindset, how do you get that mindset into an entire industry? And I think that’s, that’s really the problem that Agile has run into.

Clayton Hunt – 21:03 – Companies want to process. Which other thing, one of you said earlier, companies do want to process and that’s why we have Scrum. Scrum only exist because it’s a process. It’s only the most popular because it’s a process, but it’s a process that’s different enough that, like I said earlier, could possibly snap people’s minds out of their Waterfall existence and without it, without a full switch there, that’s not going to happen, so they haven’t taken on mentally what it is to be Agile. They haven’t taken on completely a different enough process and so you’ve got the back end of the company all the way up to the BAs because they. How many companies have you been in that are that are Agile that actually have a product owner? They still have BAs and project managers and sponsors and all that other stuff and so all the way up to the BAs, it’s Waterfall and then the BA just gives you lip service telling you that, all right, for this sprint we’re going to do these stories, but it’s still the Waterfall plan like the whole time.

Clayton Hunt – 21:58 – Even at large, very large Agile consulting firms, they have a Waterfall back end. How often? How often do you actually? The only time. The only single time that I have actually had what I would have considered to be a mostly mostly Agile setup was at a startup company that was the most Agile I’ve ever been and they still had to BA are our product owner, was the owner of the company and we actually got involvement from the owner. The owner came by for a sprint demo and retro and planning and that was. That was amazing. I haven’t had that since then, but we still had a BA and the BA basically copied, pasted emails from the owner and those were the requirements and then pretty much just like every other company I’ve ever worked at, the devs didn’t have to tell to the a how to write the requirements and what order to put them in and then the work begins.

Clayton Hunt – 22:49 – I don’t know what to do about that. I would love to do something about that. I invest emotionally and physically a lot into the companies that I work for. I want them to do as good as they can do. When I see inefficiencies in the company that are costing the company money, I get maybe a little upset or, or, or energized about about doing something about them, but I can’t seem to get anybody else energized about saving the company money, doing better processes. You know, they, they may not be scrubbed, they may not, they may not even be Agile. I mean, I’m sure they’re from the core, like the true spirit of Agile. They are Agile, but they’re not, you know, you, you wouldn’t be able to point at some though they’re not Kanban or they’re not Scrum or they’re not, you know, whatever else they’re, they’re just, here’s a suggestion that I think would really help.

Clayton Hunt – 23:32 – And in the end, that’s really what Agile is.

Jon Ash – 23:35 – Yeah, I mean, I, I think, I think that part of the issue is so there’s. I think there’s a twofold issue of the things that, you mentioned. The thing, the reality is also it takes more than just people being energized, right? They have to be able to affect change and if they can’t affect change then they can’t be energized and this is what I see in especially in the various consulting opportunities and in places that I’ve been where you see people they would be interested, they would be, but they have such existing process kind of holding them in in certain certain grips. And what’s the point of trying to get excited about something when I. I don’t even feel that I have the ability to affect any change.

Clayton Hunt – 24:28 – Yeah. I feel like that’s a huge problem with a lot of companies. In my mind. There are three types of employees. You have contractors, right? They’re there. What I expect to be 9 to 5, they show up. You tell them what to do, they do it and then they go home or you know, if they’re online or whatever, but they’re, they’re just, they’re just hired hands. They just do the work and then they leave. Then you have consultants, right? So consultants will act as experts. They will, they will guide the company, they will help the company, but in the end they’re not, they’re not invested in the company. They collect their paycheck and when they go home, if you don’t do what they said, that was a good idea for you to do, then they don’t care. Ultimately then you have the way that fulltime employees should be treated. Fulltime employees are consultants that are invested in the company, right?

Clayton Hunt – 25:21 – Everything, every suggestion they make, everything that they are doing should be in an effort to make the company better, to make the company more money, to improve the processes, any, any kind of way to make the company better. However, it seems like a lot of companies aren’t hiring, even though they might bring them on as full time employees. They’re not hiring people to be full time employees. They’re hiring contractors. Uh, I don’t think there is anything that we can do about that. I mean, how do you change, you know, once the machine is going, how do you change the entire machines direction? The only way to do it is one person at a time. But like you said, being a developer and you’re basically the lowest person on the Totem Pole, you’re, you’re at the end of the line. So how do you affect change up?

Jon Ash – 26:02 – So I think the, the unfortunately one of the biggest ways that change will be affected, uh, is that I do believe that there is real business benefit to behaving in an Agile manner and to the Agile ideas and the Agile concepts. And so that means that other companies will be out those companies that may take time for those things to become established. It may take time for, for growth to, to, to, so that’s kind of take hold. And along the way, those companies that gain that momentum may slip back into the, to, into, you know, failed methodologies of the, of the past once they kind of have no, and they’ll try to throw their weight around and they’ll even be successful. But I, I think that ultimately, the, the only way that the change really gets affected is by just simply, um, businesses.

Jon Ash – 27:01 – And I, I think I would point to, you know, the company that we worked altogether, uh, you know, we worked, we had some pretty large client, uh, and one of the reasons why we had such a, such a large client was that, uh, you know, we could write the software way, way better and faster and get the job done then then they could. And that, that was because we had a much more leaner and efficient. And in reality it was much more Agile, true to the Agile idea. Uh, we certainly struggled with our Agile specific implementations and struggled but struggled in all in, in mostly all good way to try and understand, you know, how to make our Agile experience as Agile as beneficial to us and kind of working, working the best.

Jon Ash – 27:51 – But we were able to do, we were able to, to, to enact and actually produce and um, you know, bring value and deliver value at a much higher rate than, uh, than our. And our clients were even, even though even if some of them might have been even software companies themselves,

Clayton Hunt – 28:11 – one of the things that I think is crucial for a company to be able to adapt a in an Agile way is for the individuals in the company and to realize that they suck at their job. Right? So like all of the developers at that company, maybe they wouldn’t have put it that way, but they understood that they weren’t godsend and they could get better. So everybody, everybody always worked to get better. Everybody was willing to get better. And that’s really all it takes. So that. So that when I say Ash, this thing you did, it’s terrible. You can look at it, you can evaluate it and you can know that when I’m telling you that, that I’m not, I’m not trying to insult you, I’m just trying to tell you that the thing could be better. And then maybe we need to look at it. That’s the thing that would move into vigils forward. But even that’s kind of a rare trait to find among individuals

John Callaway – 29:03 – having true retrospectives and identifying those things that, that truly went well, the things that didn’t go well and the things that you can do to improve going forward.

Clayton Hunt – 29:13 – Yeah. It’s not, it’s not just about making everybody feel nice.

John Callaway – 29:16 – So we spent a lot of the time when Agile practices in general. I wanted to spend just a few minutes on Ryan Dahl’s talk at JSConf. Did either of you see that, uh, that talk or hear anything about that on the Internet?

Jon Ash – 29:29 – Yeah, I mean it seems like a, I kind of feel like this is a very similar, like if we take a look and we were to abstract and boiled down the, the big picture idea here, uh, it’s actually a very similar situation in some, in some regard with basically what a Ryan Ryan Dahl had created in the Node.js and what the problems he was trying to solve. Uh, and then the way that people have gone about a and kind of taken the direction of things and then realizing, wait a second, I can’t actually go ahead and make the changes that I might want to be making.

John Callaway – 30:04 – I think they’re both similar situations in that, uh, we have a problem, Oh, here’s the solution, here’s the prescription, follow this. And, and really, you know, at that point if, if you get the people on board and the people making decisions and making money as a result, developing consultancies around Agile practices or, or no development than, than you really have those, those people that are just selling that as a product and maybe not necessarily doing proper evaluation around things, you know, I’m not trying to disparage node specifically. Maybe actually a little bit but, but just purely but just purely on, on the big businesses that has come up around it. But I think that node being the solution for everything is questionable in my mind in, in that. Sure. Uh, maybe you can, you can do that or are there reasons to choose node over something else?

Jon Ash – 30:04 – Absolutely.

John Callaway – 31:00 – Are there any drawbacks or or downfalls or or things to be aware of?

Clayton Hunt – 31:04 – Absolutely. So in general this, this concept of why are people doing this and this, you know, why are people doing x and y has actually been around for a while. I mean if you know C Sharp when there’s a project that comes up, your first response is going to be like, I can solve this in C Sharp is C Sharp the best language maybe is .net the best platform maybe, but also maybe not, but you know what I don’t know Haskell. So even though Haskell would be 100 times better and the correct solution for this one thing, I don’t know it, so I’m going to do it in C Sharp. Same thing happens with the same thing happens with node. So you’ve got this whole class in the last nine years, you’ve got a whole classification of Haskell developers that are coming out.

Clayton Hunt – 31:54 – They’re entering the job market and they’ve grown up as web developers so they know Javascript and so the platform that they’re going to gravitate to is node. They don’t know anything else. It’s all I know, so whenever there’s a problem of any kind, it’s going to be there, their tip top solution and for other developers coming in from other, uh, ecospheres like a new C Sharp. Now I’ve learned node, well nodes the new candy. So of course you’re going to do it in a node. If you had just learned Ruby, you’d do it in Ruby, but you’re gonna you’re gonna. Take the thing that you’re working on the most now and that’s going to be your solution for everything until you grow into it a little bit. Uh, and then you realize that, okay, well now I know, I know note and I know c sharp and I know ruby and I know python and I know closure and I know Haskell and I know Erlang and I know Element, I know whatever else.

Clayton Hunt – 32:48 – And then among those you will pick the one that you know, that you think best fits the situation unless the company you’re working for does node and then you’re going to do node.

Jon Ash – 32:59 – Well, I mean, yeah, I mean I think you kind of have to look at like what node was the problem that we’re solving and that was doing the big problem was dealing with IO and changing it from a sort of the thread where you either have to block the process altogether or you have to like spawn a new thread. We have a thread switching. Um, and so I was trying to, trying to go with that event driven design for, for, for dealing with um, IO and that does create a lighter weight solution from the web server standpoint, but it also puts, begins to put another burden on other things and including, including, um, basically the, the actual process of, of, right again, of, of uh, and, and the ability to kind of write it cleanly and having libraries and other things kind of a built for it.

Jon Ash – 34:05 – And all of a sudden you may, you know, we, we’ve learned one of the things we’re learning kind of in the very short, relatively short a existence from a of the software development of computer life as an industry is that performance. While it is important in some cases, isn’t ultimately the end of, it’s not the end all be all requirement, uh, and especially as machines get faster and, and whatnot, and the biggest cost to, to the software’s actually more maintenance and uh, the, the ability to keep, keep that, have multiple people work on that piece of software and have it to be, it can be understood and maintained and developed. And um, and so some of the issues that, that node didn’t solve, well, they may have gotten some of the performance of the web, uh, IO great. They, they may have done that well, but like the NPM package hell that, that there is, you know, basic creates a maintainability nightmare.

Jon Ash – 35:19 – Um, and it, it ultimately it becomes into a, you know, creates a situation that, that is difficult for people to, to keep, to maintain and becomes a costly a product even though it’s busy solving a product and it might be a, am I performance, but that performance may not even be needed. There may be a better solution. And that’s kind of what you’re, what you’re pointing to is it’s, you have to look at the whole, no problem.

John Callaway – 35:48 – And we love to hear from you on the subject, the article and presentation in question where Developers Should Abandon Agile from Ron Jeffries and Ryan Dahl’s presentation at JSConf 10 things I regret about Node.js.

 

Links

Manifesto for Agile Software Development (http://agilemanifesto.org/)
Developers Should Abandon Agile (https://ronjeffries.com/articles/018-01ff/abandon-1/)
10 Things I Regret About Node.js – Ryan Dahl – JSConf EU 2018 (https://www.youtube.com/watch?v=M3BM9TB-8yA)

“Tempting Time” by Animals As Leaders used with permissions – All Rights Reserved

 

 

Episode source