[MUSIC] >> This is Pragmatic, a weekly discussion show contemplating the practical application of technology. Exploring the real-world trade-offs, we look at how great ideas are transformed into products and services that can change our lives. Nothing is as simple as it seems. This episode of Pragmatic is sponsored by Typeform. Typeform makes it easy to build and share beautifully designed online forms, combining human creativity with the power of modern cross-device web technology to create new ways of asking questions online. They're uniquely tailored to act like actual human conversation, one question at a time, without what's coming up next distracting you, and the result is awesome. For a limited time, Typeform is offering a three-month free trial of their new Typeform Pro service. We'll talk a little bit more about that later on in the show. I'm Ben Alexander, and my co-host is John Chidjie. How you doing, John? I'm doing very well. How you doing, Ben? I'm doing good. Oh, I did it. I'm doing well. But that's okay. No, I almost, I mean, it's so almost there. It was all that stuff before. That's okay. It's fine. Anyway. Okay. So once again, I did a cryptic clue on Twitter, but this one for the topic for this episode is, I will confess a little bit difficult. - This one was hard. - Yeah, I know. I struggled to come up with one that even made any degree of sense. So in any case, I guess I'll, what we want to talk about today, oh, I'm getting ahead of myself. I'm terribly sorry. I should say firstly, quickly, thanks as always to all the people on Twitter and app.net have been saying nice things about the show. Also for iTunes reviews. Had another couple this week, thanks to Bassetts from Canada and Isaac Case from the USA. Some lovely things there, thank you very much. And also on the survey, I'm gonna leave the survey out for another week. Again, the link will be in the show notes for this week. So I'll leave it up for another week. So people have more of an opportunity to put their thoughts in. And I've had lots of good responses so far, thank you. So keep them coming. If you haven't had a chance to fill it in, please do. It's your chance to vote on the different topics we've covered and to suggest new topics. And people also feel free to tweet at me anytime, mention me or email through the form and make suggestions 'cause I'm always open to suggestions. So today, and I'll forgive you for not getting the cryptic clue, and that's okay. I actually want to talk about software, specifically existing software. And well, I guess the question I want to ask is to extend or to rebuild. And that's the question. So given a situation that you're in, someone hands you a piece of software, it doesn't matter what language, doesn't matter what kind, and you are faced with a decision. Do you run with what you've got or do you simply start again? And I guess I wanted to tackle this because there was, I've come across this many, many times since I've been programming professionally. And honestly, I think it's a very difficult situation. I also know this is a topic that you are very familiar with yourself, Ben. - Yeah, this is the big question. - It is. So first of all, I just want to start out by saying the way I used to be. So back when I was a wee lad, and I was learning to program and I was doing what I was doing, I must admit, I was very much convinced that I knew everything there was to know about. You know, I could write a better code than this person. Why did they write it this way? I'm going to do it this way because this way is my way is better. And the older that I've, older I've become, the less I am seeing the world that way. I begin to see the time investment that people put in when they write code. And I begin to see that a piece of code that is, you know, several pages long could represent weeks of development and testing, testing edge cases, test to make, test to break, all that other good stuff. And yet there I was as a younger programmer thinking, I can do it better. And the reason that you think that's simple is that you don't, all you see is a few pages of code and you're like, I could write that. I really don't like the way they've used their floats or whatever. Maybe they haven't used floats, they've used integers for some reason. And you say, "Well, I'm going to go to floats because floats are better." And then, of course, you find out after you do some math, you get some precision issues. I don't know. But the thing is, you don't see all of that hard work, all that effort. All you see is a bunch of lines of code. And you think, "Well, how hard could it be to write that?" And I guess that's the trap. So the big case that I had in recent memory was a large pipeline. Some of the details, I think I'm safe enough to talk about it. This particular pipeline was a water pipeline and there were 43 PLCs and two main SCADA servers all running a common executable with multiple clients. And this pipeline is about 120 kilometers long, so decent, decent sized pipeline, and carries quite a lot of water, drinking water. So in order to put this together, there had been two stages. The first stage, there were only 16 PLCs. The second stage extended that to a total of 43. During that extension, however, there were code modifications required for the existing 16 PLCs. And that presented some issues. We were taking over from another company and this other company had done a, shall we say, had had a different approach to how the software should be written. The way that they had written it was, I was gonna say better for programmers, but was it true? I suppose to some extent. What they'd done, and I realized that, yeah, I'm gonna talk about PLC coding, but there's no difference really in the concepts behind this. So it doesn't matter if I'm talking about, you know, Objective C or C# or Java or JavaScript or whatever, it's all about modularity and it's all about documentation. So they had written, essentially the idea was that there was a lot of repetition on the pipeline. So an offtake where you would extract water from the pipeline, there were multiple offtakes and each of these offtakes would have very similar code, similar devices and so on, but they were all subtly different. And the way that this other company had handled it is that they'd created essentially a master copy of the code complete for one controller, one PLC. They'd replicated it, you know, five times, let's say, for each of the other offtakes. And then what they've done is they had simply coded out through options, simply coding them false, putting them on code sheets that were never executed. But the code was still there, hadn't been deleted. It was just sitting there dormant, never getting run. And said, here you go, here's your modified version. And that was, I suppose, quicker and easier for them. But they had a few problems. First problem was they didn't document it. You had to trace the code through yourself and figure out what on earth they'd done. Which meant that essentially there were a lot of red herrings in there. you would go and trace a line of code and think, oh, this is causing this to happen. But it wasn't, the code was not being fully executed and it wasn't clear when the code wasn't being executed because sometimes the code was on sections of the page that were being executed, but this little one corner of it wasn't. So essentially they had a bunch of objects in there they weren't using that were deactivated, never called, and it was difficult to trace that they were never called. So the issue was that they had been very generic in their naming conventions. So everything in this code was non-specific. It was not down to an individual device. So you couldn't trace specifically. So if there was a particular device that had a generic name, all of the five copies had the same generic name, despite the fact that in the real world, they had different names. So we were told, take this code, it's fully tested and working, which was a lie, and extend it and replicate it. And here is a budget and here are not enough people. And here's a unrealistic timeline. All the usual things you get told by project management. So the dilemma was, do we do exactly that? Do we simply replicate it and extend it where we have to? Or do we just draw a line under it and start again? I dug through this code for months, for probably two months, trying to look for common patterns. And one of the things that I saw time and again was that all of these people that had been writing this code had a different approach. And the structure of their code for the different, the different locations was not the same. So what was happening was you were getting a big divergence in the quality, not just the quality of the code, but also the quality of the replication of their code. As if someone had given someone a direction and they'd misunderstood and they'd gone off and done it and there was never a check done. Here's an example. Imagine you build yourself a class or an object and there's a bunch of code inside it. Now, the idea would be that you would then have version control on that object, and you would say, okay, well, I'm going to test this to death, and I am going to put it away over here, and I know that it works and it's solid. I don't have to worry about it anymore. What they had done is they had taken the insides, parts of the insides of that code, and replicated it, as in copied and pasted it, into a section of another object in order to get the functionality, rather than simply linking that object to the other one and then using that functionality, which would have of course kept it encapsulated and version controlled and fully tested, but no, they didn't do that. They extracted parts of it to get that functionality in a different object. So the code control was horrendous. It was just horrendous. I was comparing line by line code to figure out whether or not this actually came from the same master. In some cases it did, but what had happened is that they found bugs and they'd fixed the bugs in the common object, but they didn't fix it in their copy and pasted version and their Frankenstein version, if you know what I mean. It was just a mess, an absolute mess. And as we were testing it in our tests, we found issues with the code and we went back to the client. And we said, are you aware that in this situation, this file to close something is locked out and doesn't function? And they came back to us rather cheekily and said, oh, yeah, we've been aware of that problem for the last two months and the other people have fixed it. And we're like, oh, well, when were you going to tell us that? Because they'd given us a golden master of the code. What they didn't tell us was that they were still using this other contractor to work on the existing code to fix the close out bugs and they were not keeping us in the loop. So we were told, take this code, it works perfectly, which it didn't. You know, copy the blocks, which we couldn't because they were all subtly different. And then they continue doing code development on the code base and never told us. You know, when we, the webshop, when we started doing apps, my lawyer or drop our contract and a lot of time on it. And I said, just drop a contract that I wouldn't sign, right, like be very aggressive for us and protect us from some of this stuff. And one of the things was that, was that if you did that, if you were working with someone on some aspect of the project and we weren't aware of it, and it was relevant, that essentially it was a kill switch, right? We could just take it and walk, keep the money, all that. Because we ran into similar things where we developed a system, you develop-- it doesn't even have to be programming. I mean, your marketing approach, have something come in and you don't know what's going on, you don't even know it's there. It's crazy. It's crazy. It's nuts. And it can ruin your reputation. it definitely had an impact on ours because we were, unfortunately, the budget was set by people in the organization that had no idea. They simply said, here's existing code. We're assured that it works. Let's just copy and paste it and extend it. That'll take less time than if we're developing it from scratch. And that assumption is that, I mean, that, that train of thought is logically correct. However, that presupposes that the first fact was true, which is that it was functioning and it was good. So what I learned from this is it helped me to focus because you have to realize I was involved in this project for three and a half years. - Multitude just eats your life. - It was. The pipeline itself, the overall project cost was $330 million. The cost for the control system software component, I'm not at liberty to say how much it was, but it was in the millions. The project manager who had, sorry, the project manager, no, the software lead on the project and the team lead for the electrical instrumentation and controls changed multiple times. And me being the sort of person that I am, I just seem to end up in a situation where I'm always the last man standing. I don't know why that is. I just, it just seems to be my, the way I, than my lot in life. I don't know. I don't really begrudge it because I get- I guess I have this thing where I like to see things through to completion. I hate seeing things unfinished. Yeah. It irritates the hell out of me. So maybe that's why. That little facet of my personality makes me drawn to those situations. So where other people are likely to pull up stakes and move on, I'm more likely to sort of like dig deeper and just like, no, I'm going to see this through." And I remember when I was in another one of my jobs previously, I used to get very vocal with the managing director when he would take me off projects. And I'm like, "Well, hang on a minute. And I'd like to see it through." And he's like, "Well, no, I need your expertise on this." And I'm like, "But I want to finish it." And he said, "Well, I'm sorry, but no. I need you here." So we always used to irritate me. So I guess in this particular project, I was lucky because I was able to stay through to the end. Painful though it was. So in the end, after all the other leads went, there were three other leads that went, it ended up landing in my lap. So I started this project, I wasn't the lead. I was lead software architect, however I was not actually the lead of the entire department and three leads later I ended up actually being the one holding the whole bag. Yeah, which was fine, not a problem, it's just that, yeah, it was a very long winding road. Anyway, it had a happy ending, for whatever it's worth. Good. Well, I mean, it works. It works. Right. You got it. And the code is at least a heck of a lot better than what they started with. But that, the musical chairs for your leads, like that's a bit of a, well, not a code smell, I guess, but a process smell. Yeah, well, what it was, I think you're on the right track. The bottom line is that something smelt bad, right? And each one of them, the last one was the most hilarious because they're actually a contractor. And in order to be a lead by the rules, you could not be a contractor. You had to be a full time staff member. And I know from my personal conversations with this particular gentleman that he had been He was being courted by another consultant and they said, "Hey, you know, he's like, I'm just waiting to hear back from such and such." He'd been waiting for six months. Now, I don't know if this is public knowledge or not, but in the end, he saw no choice, but he had to take the role as the lead. So he came on full time. But once he switched from his contract contract to his full-time contract, he was then technically on a probationary period. And that probationary period could be terminated within a week's notice. And that's exactly what he did one week into the full-time role. He handed in his resignation because the other consultant had finally got around to making him the offer that he accepted. This sounds a lot like the doomed startup. This is a different name, same story. Really. Well, the thing is with this project is that I did a little bit of the, well, I did a reasonable chunk of the PLC programming at the block level. And I did some of the integration, but most of the replication and commissioning for the PLC site was done by other people. The SCADA side of it, however, we had a SCADA engineer that worked for us for a few months and he didn't work out at all. I was sort of, it was generally considered a positive for the project when that relationship ended. And we were then SCADA-less for nearly a year, and that got way behind schedule until the point at which I basically said, well, you know what, if no one else is going to pick this up, I'm going to pick this up. So I was running all the other stuff as well as the specs, as well as the reviews and all of the HAZOPs, and I was doing the damn SCADA. So I ended up actually doing probably about 80% of the SCADA for the entire system, which is on top of everything else, which was a little bit stressful. But anyway, look, I didn't want to get too bogged down into those details of the project. But in any case, it got me thinking about What is the difference between software and particularly, I guess, software libraries as a product and software as a whole as a product? Because they are two very, very different things. Because what we've been sold on, on the beginning of this project was the individual blocks that you're going to copy, the objects, they've been tested to an inch of their life, they're rock solid. You can just copy and replicate them. and here's your user manual, except there was no user manual and they hadn't been tested properly and so on and so forth. So what they were saying is, here are your software libraries as a product. Now here's essentially an API that you can call and it's all solid as a rock, all you gotta do is replicate it. That's literally what they were saying. And that would be software libraries delivered or software libraries delivered as a product that you can then integrate into your own project and have confidence that it was solid and that it was going to function correctly. The other form of the software would be, we're going to give you the software as one big executable and you can now use that executable to do whatever it's meant to do. And the way I suppose the analogy I thought of at the time was, it's like Microsoft saying, Here are all the bits you need to build Excel. Here's all of the different APIs and everything that you're gonna need to build a functioning version of Microsoft Excel, go for it. Or here's Microsoft Excel, the complete product, we'll now support that. Two extremely different things. So, honestly, if you're in a situation like that, my first word of caution would be, look for the documentation. It sounds simple and it is, I guess, but generally, well-documented software has been written with a thought of someone else is going to have to understand what the heck I've done. So if I'm passing a bunch of values to this object or a bunch of transactions with this object, I need to know what I'm going to get back. And I need to know it's going to work reliably because believe me, I Get to this in a minute, I guess. If there is a documentation, that's a good sign. Of course, it could still be BS. I mean, you could get documentation that tells you something that's incorrect, but generally speaking, what I found is that if there is documentation, it's a good indicator. I would be also running, when you're given the software, I would run a couple of test cases before you get too fully blown into the integration. I would say, right, I'm gonna do a couple of test messages back and forth. I'm gonna write a few values, get a few responses, and I'm going to do my own little spot checks. Even if they're random, something, you know, like build a test environment and test that before you start doing the whole full integration with whatever you're trying to do. - Right. Looking for signs, looking for cracks in the problem. - Exactly. Yeah, I mean, poke and prod it, right? - Yeah. - Poke it with a stick and see if it falls over. - Yeah, like whenever I'm looking at a new library framework or tool or whatever. You know, I'll run a stand up, make something really quick and dirty and with no intention of ever doing anything with it. But just for that, looking for the issues. Just to get an idea, get a feel for it. Yeah, exactly. And I think that that's an essential step. Because it's your way of validating. Right. A lot of times it's just like a gut feel too. Like, I can't parse it out exactly, but a lot of times if I ignore those gut feelings, it'll bite me. Absolutely. So, the other thing that you have to keep in mind, and this is one of the things that I'm not sure if this is a common belief or if it's a mis... Maybe I'm misunderstanding the way other people may think, other programmers may think. But honestly, I always go into any API framework object that I've been given to work with, or I've chosen to work with, with the opinion that something will not work. There'll be something wrong with it because there's no such thing as perfect. Nothing is perfect. And nothing is as simple as it seems. Or you think you've got all the documentation. You think that everything that's written there is fully documented. Well, I'm willing to bet it isn't. I'm willing to bet there's some combination of messaging and inputs and outputs and linking that is not detailed in there that you need to actually make it work properly. There's assumed knowledge, you know, and what if you're coming from a different background, different area, different scope of expertise, and someone says the documentation's all there. Well, it's all there if you've had experience with a similar framework, perhaps. So I guess the assumption, never make the assumption that anything is ever 100% solid. Assume that there's going to be a problem with it somewhere. And if you find one, it doesn't mean the whole thing is bad. Mind you, if you find two or three or four, that's really not a good sign. Like you said, it comes down to a bit of gut feel really. Can't just take it on face value. And that's why companies like Apple have got the radar system, right? So you find a problem with their code, you submit a radar and you hope that they fix it. And it's absolutely critical. So don't assume that it's going to just work. Always believe that the code is fallible and it's going to fall over. And one of the ones I've... The thing is, I work in an environment where the stability of the software you're using and the PLCs you're using, the SCADA software that you're using is extremely important. And you would think that on systems that are controlling, well, very, very expensive hardware and are monitoring it for all sorts of reasons, for environmental purposes, legal reasons, that there would be a lot of work done on the stability and the accuracy of the APIs and everything. One bit of software that I have used, unfortunately, for a lot of my, well, a fair chunk of my career, at least doing SCADA programming, is some software called Scitect. And it was a company in Australia that develops sort of like a multi-purpose SCADA with all these drivers for different PLCs. And what they did is it was sort of written, they had their own kernel that would sit on top of the standard Windows runtime. And it was pretty solid in and of itself, but it was written in the '90s. And it continues to be used today. was bought by Schneider Electric, and I think now it's slowly dying, which is, you know, I think on the whole, probably a positive for the world. But in any case, the API in there was essentially 20 years old. They'd been extending it, of course, and, you know, adding new features. So on this particular project, which was also using, you know, SciTech, in there, they had a bunch of functions in SciCode. And these functions, they call it is their custom scripting language. Yeah, Cytec, Cycode, it's all very silly, but anyway. Yeah, yeah, yeah, grown, but still. Anyway, so I call this API and I don't get the response I'm supposed to get. So I'm like, okay, that's odd. I try different calls. I try and do, I try and kick it off at different times. I try and make sure that it's happening in the right sequence. I put other things before it, like I clear a variable out before it, then I pass it to it, I clear it again. And I try all sorts of different things. The thing that finally got it to work is I called the same function with exactly the same values twice in a row. It would fail the first time, but it passed the second. That is solid. - You had to warm up the cache or something. - Like, yeah, you had to warm the API up before you get an answer out of the damn thing. So, I mean, that's solid, man. That's, you can take that to the bank. I mean, come on, really? Have I got some old code to show you, John? I'm sure you do. But, you know, this is the thing is you would think after 20 years that that code would be solid. No, it wasn't. Terrible, just terrible. Anyway, so I feed that back to the company in question and their response was, yeah, we haven't really seen that before. Are you sure you're doing it right? Anyway, I sent them the code and I never heard back from them after that. So maybe they saw the writing on the wall for their product and just said, well, what's the point of fixing it? We're going to get canned anyway. I've got a theory about that. That sort of thing is that your worst mistake, your biggest problem, that that is also the most likely one for you to crystallize and just make central. because it's often something that would be too painful to make the switch. Sure. Fix. I just see it again and again in my own stuff and just in other people I've worked with and in life. Yeah. Well, the truth is, from my point of view, from a purely, well, pragmatic perspective, I had something that worked. I was simply telling them as a courtesy. Yeah. "Hey guys, by the way, this is crap and it doesn't work. Please fix it and save someone else the grief that I went through after." I mean, it probably took me three or four hours, something like that, to figure out how to make that API respond. Basically, kick it twice. And they're not... They just didn't seem to care. So I found it to be very disappointing and very frustrating. But in the end, you know what? Hey, I got the result I got the answer back from the API. I was able to proceed with my code and I got a positive result. So, hey, it's okay in the end, isn't it? At least for me. And I'll remember that for next time, but then I'm really sincerely hoping there is no next time, at least for that product, 'cause it needs to be sunset quickly. 'Cause there's far better products out there. I mean, it was built back in the days before. It's not IO, right? It just isn't. The templates are terrible. Everything's based on DB4. So, when you add a graphic or a symbol or genie or whatever you add to the package, you have to update libraries. You have to pack pages and pack libraries and then compile the project. I call it the four-step magic process. That if anything goes like crazy and you do one work on a screen, you compile it and you get some kind of gibberish, it's like, "Okay, well, I've got to go and do the, pack libraries, update pages, pack project, compile project. You got to do the four-step magic process. And then suddenly magically it'll be fixed. And the reason is that everything was cross-linked in DB4. They weren't linked lists, they weren't active. The databases did not automatically refresh all of their indexes. So what would happen is you would, if you deleted something, then it would be flagged for deletion, but until you packed it, it wouldn't actually get rid of the data. And anyway, I'm sorry, I'm getting too- - I could hear it in your voice there. - Oh, mate, years and years and years of beating my head against the damn desk with this software. - I get it. I know you're, I'm sure many, many people in the audience feel that way too. They've got something like that. - Yeah, well, this is the problem is I'm skeptical about going on ranting too much about the details about SciTech specifically because, yeah, whilst I'm aware that there are some listeners that a control system program is for most people, it's going to be like, what, what the hell is a Cytec and who cares? And that's fine, but insert your tool of frustration here. Xcode has its foibles as well. And there's still people that are pissy about the fact that Apple went and integrated all of it into one IDE, into one window. So back when, was it Xcode 3, I think it was, had the interface builder and it had the-- - Yeah, they were separate. - They're all separate windows, right? That's all gone. So it's now one unified window and, you know, honestly, I've used both. I did the development on my bedside clock back in Xcode 3, but I've used Xcode 4 since. And, yeah, I don't mind it. I'm not really all that fussy either way. I've gotten, you know, it's. I don't use it for anything other than than that, right. And it works fine. I mean, you know, it's I think I'm on the same page with you where. It feels like it's good for what it needs to do. But yeah, it's still, it'll be chafing sometimes that I would like to just be able to peel part of it off and have it sit over on the other screen. Yeah, but I mean, the bottom line, but that's the blind text for that. So whatever. Yeah, sure. Sure. Absolutely. I mean, I've been using TextMate a lot lately and I've fallen in love with TextMate. It's actually really nice. I can't believe that I've lived without it for so long, actually. Yeah. It was one of those aha, light bulb moments when I went to Statomic and I'm like, oh, all right, I'll try Sublime Text. Okay, I'll try this and Textmate. It's like, whoa, hey, this is actually pretty good. I like this. But anyway, okay, before we go on any further, I was wondering if you could tell us a little bit more about Typeform. - Sure. Typeform is a fresh solution to the big problem of gathering data on your website. Forms are a key component of doing business online, but up until now, they've meant a lot of work to design, configure, and administer, and the results have usually been pretty unflattering. There are other form builders out there that take care of some of the problems and make it easier to get something basic up, but creating something great is still hard. Typeform is the only form builder that allows you to get unlimited responses for free. As many questions as you want, as many answers as you get, Typeform doesn't limit your interaction. Typeforms are beautifully designed and have cross-platform compatibility baked in. They're tailored to look and work differently on desktops, on smartphones, and on tablets. Design is about how it works, and Typeforms are built to really work, regardless of the device. The platform itself is a joy to use, both as a customer creating a Typeform and a user interacting with one. The UI is sexy, clean, and fast, and designing even complex series of questions is made simple through their dashboard. UX is focused on asking and answering one question at a time, so it doesn't feel overwhelming and nobody gets lost. Typeform champions good user experience and design. This helps you create a space in which users will be more willing to answer and more likely to give honest answers. From customer feedback and surveys, contests and landing pages, event organization, in the classroom, Typeforms let your imagination fly. People are using Typeforms in a huge variety of ways to make interactive stories, holiday cards, team presentations, avatar creation, the list goes on and on. For a limited time, Typeform is offering a three-month free trial of their new Typeform Pro service. You can sign up by visiting typeform.com/fiatlux and you can upgrade to the pro plan from the dashboard. Make sure to use the coupon code FIATLUX to get your free three months. Thank you to Typeform for sponsoring the show and for making it easier for people to get to know each other better. It's awesome. - Okay, thanks for that, Ben. That was awesome and I strongly recommend giving Typeform a go. I did and honestly on the survey so far, it's been a pleasure to use. So, definitely check it out. So, but I guess just quickly about Xcode and SciTech is that I lived in SciTech for years and years and years. So, you know, and that's fine. And I don't live in Xcode each day, every day. I just don't. And I'm probably not going to because, well, I've got another job, you know, programming another software. And even actually in terms of programming, most of the stuff I've been doing lately has been more architectural, higher level stuff, which tends to happen when you get to that sort of to the point I am in my career is you tend to do less of the hands-on and more of a high level. And you tend to yell at the younger engineers and programmers and say, hey, you should probably do it this way. Do you like that? Do you like that process? I mean, a lot of developers, a lot of engineers don't. They probably hate it. You mean how-- No, not yelling at people. Oh, no. I was going to say, what are you asking me, Ben? Moving up the stack. Yeah. Move up the stack. Look, I find the whole thing to be very frustrating because no matter which way you go, someone loses something because on the one hand, you'll have the technically excellent people and the technically excellent people, if they are happy being really good at what they're doing and they want to keep doing what they're doing, then you want to keep them in a technical role. And that works fine until they see the dollar signs. And they say, you know what, I actually would rather, I'm sick of working, you know, like 18 hour days, seven days a week, you know, in control systems. I'm sick of working out in a mine site, you know, underground in a bunker, in a switch room, wherever the hell I'm working. I'm sick of that. I want to go back to a nice, cushy desk job in an office somewhere where I tell other people what to do and get paid more. Mm-hmm. Right. And when that happens, no matter how talented or good they are, they see the dollar sign and they go chasing after the bag of money. So, you know, I've met people that are in their 60s that are still doing control system programming. Both my in-laws write COBOL for banks. Right. It's like real legacy code, but they've just... Yeah. It's been doing it for 30 years and it's fine. There's still a need for it. There was this one guy I came across and he has hair like Einstein. You know, like seriously, it was just like sticking out everywhere and he looked a little bit crazy. But cheesy was good. He was so good. And one time he was walking me through one of the progressions that he was doing for a stacking algorithm. So we're stacking panels on, stacking and sorting. Anyway, long story short, anyway, he's going through the hexadecimal and he's saying, I guess, so now I do a rotation here and a shift there and I pull this out there. And you see by sequencing it this way that it makes it so straightforward. And I'm like, oh, man, that is a really good idea. But of course, why? He'd been doing it for 30 years. He started programming with Modicon 084s and here I am. I've only been doing it at that point. I'd only been doing it for about five years. But, you know, he was getting close to his 60s and he was still programming. And I sort of, you know, at the time, you know, being younger at the time, this is going back over to 11 years ago now this happened. And I'm thinking, well, why didn't you go into management? I thought that's what happened when you sort of got older. And I was starting to come across people that were technically minded that stayed in their technical stuff. You know, he loved it. He was happy. He was making enough to be happy. He didn't mind the site work. Good for him. Fantastic. So, that's the problem. People with the technical ability that are good at it, people think, "Oh, well, they're good at the technical stuff, so they're going to be good at the management stuff," right? And that's completely wrong. It's a completely different skill set. So, you end up with people in management then that are technically very good, but from a management point of view and an interpersonal point of view are terrible. I mean, that's a generalization. They're not all terrible. I like to think that I'm not terrible, but I'm not really the best judged person to be answering that question. Ask people that work for me. And believe me, I've heard a mixed bag on that one. So, let's not go there. We'll not examine that too closely. So, on the other hand, though, let's look at the other option. The other option is you do a little bit of programming, not much. You're not a technical wizard and you realize that the path to management is, let's say it's through project management. So you start out doing project management and watching people's deliverables and then doing performance reviews. And before you know it, you're working your way up the chain of management that way. And you start managing projects that you have no technical knowledge of how they're actually put together. And that's very dangerous. You're actually managing people as people. You're not actually managing what the people do because you don't know what the people do because you're not technically detailed enough. You don't understand it. So how can you manage that which you do not understand? Right. And it's a weird- There's a weird line there, right? Where you can- You know, like we were talking, we were using the example, you know, think about it like a class and you've got your public methods and private methods. is like, you don't need to know everything that goes on, but you need to know enough. You need to know the right messages to send. And if you don't, or worse, if you think you do and you really don't and they're not pushing back on you, bad news. Absolutely. So I find that the progression up into management has many flaws. But in the end, someone has to do the management. someone has to look at what's going on and make a judgment call over what matters and what doesn't matter. It can't come back to each of the individuals because each of the individual give a different answer. You got five people working on a project, you're going to get five different opinions about which part of the code needs the most work. Yeah, so you can't work that way. If you work that way, then you're just going to get a random mess. I don't know. You have to have- Sometimes I think if you ask one person, you'll get five different opinions. Well, that's the other problem. People change their minds. So, yeah, if you want to avoid rework and have some coordinated approach, a coordinated approach is better than no coordination. Yeah, if you've got five people and they're all going in different directions, you're going to get a net result. Yeah, it's the whole- -Cowboy code. -Put a rope around their waist. Yeah, put a rope around their waist and then tie a knot in the center. You put five people and you say, "Now walk whatever direction you want to walk." They're all going to walk in a completely different direction and you're going to get this, the knot in the middle is just going to wander all over the place and probably end up back where it started when you're done. Whereas you get those five people pointed in generally roughly the same kind of direction, doesn't have to be exactly the same direction, then that point will move forward. So if management is not capable of doing that, they shouldn't be in management, but unfortunately, too many people I've seen get away with not knowing what they're doing and still being in management positions because there's a different set of performance criteria. And don't get me started on that. That's a whole other topic for another episode. Yeah, that actually is another topic, I believe. Yeah, it is actually another topic. But yeah, for the moment, let's leave that one there. So just to circle back quickly to where we started, and honestly, I knew that this episode was not gonna be a big long one, so there you go, that's fine. But when you are doing, when you are told you need to extend or develop software or reuse software from someone else's written, check for the documentation, poke and prod a few times to make sure it behaves the way that the documentation says it's supposed to. And if you're having major issues with it, flag it as early as you can. And go back to whoever's asking you to use it and point out, "Hey, I'm having issues with this." Because frankly, if someone had have done that exercise that I did spend a couple of months early on during the tendering, the quoting stage of the project, it would have been a very different financial outcome, at least for the control system component. Unfortunately, assumptions make an ass out of you and me. So the person doing that quoting made a horribly bad assumption. That was due to the lack of their technical, well, I would say it was more technical, that either they didn't have the time or they were technically lazy. I believe they had enough technical ability to figure that out. But for whatever reason, they didn't. And I've never had a straight answer because I know this individual. I never got a straight answer out of them. It's kind of hard to walk up to them and say, so why'd you screw the budgeting up on this? And they're like, oh, let me tell you why I screwed up. Oh, wait a minute. No, I never screwed up. Hands on hips. You screwed up. Blah, blah, blah, blah, blah. Well, that's it in a big way, though. I mean, if you can't go up to someone and say, why did you screw that up? It's hard when the person's got 10 years more experience. Well, right. But I'm not saying it's not common. And I get it. Like, that's the standard operating procedure for the world is people are defensive. But, boy, it's a lot nicer when everyone can just admit that they're human. They're going to make mistakes and you can learn from each other. Yeah. It's hard to get that culture. When those mistakes are a million dollar mistake, that's kind of frustrating. Right. I'm not actually saying it cost us a million dollars. No, but yeah, well, people are scared. They're going to lose their jobs. It didn't, but it was a sizable chunk of change. So, I, yeah, it's very hard to know. I tend to be very self-critical. Someone says, you know, oh, you screwed this up. My initial reaction is to agree with them. Probably, I probably did. However, the truth is that what I did particularly on this project was I burnt more time up front to save a hell of a lot of time later. And convincing people in project management that that was the case, it took two years for them to see it. But in the end, for whatever vindication that I could take out away from it, the programmers that were sceptical, that took my direction in the beginning came back and thanked me. It took two years. They were skeptical. They went to the project manager behind my back and even said, "What John is proposing with the code rewrite for these sections is going to take more time." They didn't trust me, but I made it happen anyway. I pushed it hard. They did it. We got a good result. We got the only good result we could have gotten. We had a working system. And the end they came back later and thanked me. And sometimes you've got to do that. And it's hard. You've got to have confidence that what you're proposing is the right solution. And if you're told, "Extend this," and it's a stinking pile of crap that doesn't work, well, you know what? Push back and don't do it. And honestly, that's pretty much all I've got to say about it. If you want to talk more about this, you can find John on Twitter @JohnChidjy. It's the same on App.net, and you should check out John's site, TechDistortion.com. If you would like to send an email, you can send it to
[email protected]. I'm Ben Alexander, and you can reach me on Twitter @FiatLuxFM. You can follow @PragmaticShow on Twitter or @Pragmatic on App.net to see show announcements and other related materials. I want to say a final thank you to our sponsor, Typeform, for sponsoring this episode. Make sure you check them out. Thanks for listening everyone. Thanks, John Thank you, Ben [MUSIC PLAYING] [Music] (thunder) [BLANK_AUDIO] [BLANK_AUDIO]
