What Do You Wish You Had Known When You Started As a Developer?

Sharing from our experience is one of the most important ways in which we can help the software developers and engineers that are just starting out. We asked some well-known and respected names from the industry what they wish they would have known when they were starting out. Discover tips and stories from Mary Poppendieck, Mike Amundsen, Allen Holub, Bernd Rücker, Aino Vonge Corry and Uncle Bob Martin. 

Intro: What are you supposed to do at work?

Mary Poppendieck: Hello, everybody. It's good to see all of you today. We're going to talk about what you wish you knew when you had your first coding job? What did you learn later, and maybe a little bit about how you learned it? And because I think stories are a great way to start, I'm going to start out with my own story and pretend that I'm not the moderator for a while.

My first job was in Naperville, Illinois at Bell Telephone Laboratories in 1967. And in 1967, they had just started coding, putting, bringing up the number two ESS, electronic switching system. They had moved all of the people working on it out to Naperville. I came from Milwaukee, so I was nearby, and I got a job there, maybe a couple of hours drive from my home.

What they were building was built on individual components, and it was to replace the electromechanical systems, telephone switching systems in the country. The very first number one ESS was installed in 1965. That was two years earlier. Before that, all the switching systems were just plain relays and microwave communication and stuff like that.

The design goal was to be as reliable at approximately the same cost as electromechanical systems that were already existing. That meant the maximum downtime goal was 2 hours in 40 years.

Now, these computers had discrete components. So, there was nothing to say that they would have anything like...

There is nothing to say that they would have anything like 40 years life out of all these individual component computers, but they had a complete dual computer system where all of the lines went into both, and they match each other up. And when one of them didn't match the other, somebody's software went through and threw the bad one out, and there was a four-hour downtime on average to bring the computer back up in order to achieve the design goal.

So, I was to write the software that would go through and check all those individual components on a card and go through all the cards on the bad computer and figure out which was the bad card and print out at a teletype so the repairman go change the card out, and then it was changed out, and it would put the back computer back up. So, that's what I did for the first year.

What I wish I knew then was, you know, this was quite an amazing thing. I assumed that everybody knew what they were doing, that all of the people who decided what should happen were smart and were in control, and they knew what was going on, and they knew how to make it work. So, whatever anybody told me to do was the right thing to do.

And I learned some years later that that was a really bad assumption. I didn't actually learn that at Bell Labs because they were pretty good. But I was working in 1976. Okay, so it's just about 10 years later. Now I'm at General Motors, and I am programming a minicomputer, TI 990, to control an automated vehicle. And because it's a TI 990 that had no high-level language, only assembly language, but hey, I was good at assembly language.

We would take it out on the test track. We would test drive it. And there was a driver to override it. And every time we went out to test my code, that was the speed control, you know, it's just plain old cruise control. But cruise control was not a self-problem down at 0 to 30 miles an hour.

So, this was 0 to 30 miles an hour cruise control. Every time we went out on the test track, it would go zoom, and then slam on the brakes, and zoom and slam on the brakes, until the driver cut it out. It just wouldn't work.

I could not get it to work. I checked everything. And I was, as I said, a pretty good, assembly language programmer. But then I decided to ask the engineers about the algorithm that they had me program. "You know, where did this come from? Are you sure it's right? Could it possibly be the algorithm?"

Well, they, of course, assume that it had to be software because who could program an assembly language with all that complicated stuff? And I got very frustrated. So, what I did was I decided that maybe the algorithm was wrong. And they didn't have their time of day to look at it.

So, I went, and I bought this book here, "Automatic Control Systems." This is a very thick book. It was the college textbook for control systems at the time. And I read it cover to cover. 

They gave me this article, they said these people at Ohio State, they're doing the research on this 0 to 30 cruise control. And here's the algorithm. And they showed me this research paper. That was all they did.

I couldn't read the paper. So, I read the book, understood control theory, read the research paper again, then looked at the algorithm. After a couple-three week, I got to the point where I could find that there was a mistake in the algorithm they gave me. So, I went to the engineers again, finally, and I said, "You know, it was the game." And if you know what the game does, it goes zoom and breaks and zoom. And it was off by about a factor of 100.

I went to the engineers, and I said, "So, you know, this constant right here, based on this in the paper, don't you think perhaps it should be this number, which was the order of two, orders of magnitude delay?" And they said, "Oh, yes, you're right."

I put in the new game, and we went out on the test track, and it worked. That's when I learned that your job is not to do what you're told. Your job is to understand what results you are supposed to get and figure out what it takes to get those results even if it means studying a college course in control theory. So, that's my story.

Recommended talk: The Future of Software Engineering • Mary Poppendieck • GOTO 2016

Aino Vonge Cory: Good story.

Preben Thoro: I love it.

Mary Poppendieck: Okay, so who would like to go... No, anybody got any questions? That's what I'm supposed to ask next. Who'd like to volunteer their story?

Mike’s story: What is your starting point?

Mike Amundsen: Well, mine was a little less entertaining, but I'll go ahead and offer it anyway just to get it out of the way. So, I got into computers rather late. I never studied computers in college, I was bad at math. I was a musician. I was looking for work and computers had kind of entertained me from a hobby side. I kind of pitched myself. This is the microcomputer era. So, I said, "Oh, yeah, I can do that."

It helped and I worked in a social service organization in Northwestern Ohio. They needed to keep track of a lot of information about patients, and care, and budgets, and all these other things. So, I understood this kind of stuff.

They said, "Well, we need to buy some computers." And I said, "Well, I'll help you buy one." I made sure we didn't buy the new hipster computers. I made sure we bought the tried-and-true business computer that all ran CPM. So, at least somebody appreciates that decision.

Recommended talk: Discovering RESTful Web Microservices: A Traveler's Guide • Mike Amundsen • GOTO 2019

Allen Holub: You did little research?

Mike Amundsen: Yes, I did a little research. And so, I started building. But here's the thing, I understood that when you program computers you are programming lots of small utilities and stitching them together. I didn't really get this notion that there's this large-scale application that you design and build, and you review, and so on and so forth.

I built it piece by piece by piece. I learned all about pipes and filters and everything else. It turned out that I built lots of really great utilities that no one else could use. So then, I solved that problem by writing a script that everybody could just type one thing... Because back then it was still all command-line interface stuff.

So, what I learned in that process was your perspective, your starting point is super important. It took me years before I realized, "Oh, there are interfaces and there are large-scale applications. And I really should have learned that a lot better."

Now, the good news was when I got involved in the web and APIs and services and distributed systems, all that command line utility stuff was really paying off because I had that built-in in my head. And I still do today. I still build a lot of little DSL utilities and that kind of thing.

Mary Poppendieck: So, you never actually learned, right?

Mike Amundsen:  No, I never did. I never did, honestly. I'm not to be allowed near any real user experience material because I just never got it. Honestly, I just never did.

So, instead, I continue to write these small utilities or these little connectors that saw little job runs these kinds of things. I've been able to carve out an enjoyable experience from that. But I definitely made some really bad assumptions early on. And it cost me quite a while.

Now. It turns out, I adapt, and I learned enough. But I had started from a very unusual standpoint. And that was in the early '80s. It must have been '81, '82 when I started. That was it.

Mary Poppendieck: Any more comments about that? Any more magicians?

Allen Holub: Magicians, you mean, musicians?

Mary Poppendieck: Yeah, musicians.

Allen Holub: Magicians too.

Mary Poppendieck:  We're all magicians.

Allen Holub: I'm a musician.

Mary Poppendieck:  You are?

Allen’s storyL The way in which you write your code

Allen Holub: I am. I got into computers because I was interested in computer music. I was actually a medieval history major at the time and ended up graduating with degrees in both. But I started taking CS classes because I wanted to program synthesizers, which I don't use anymore.

Mary Poppendieck: So, tell us about your first and what you wished you know.

Allen Holub: My first job, actually, I started out as a hardware engineer. So, my very first job was not a software job. In fact, I personally with my own hands, built the error correction board in the Hubble Space Telescope is that it was all, it was wire wrap and ECL logic if anybody remembers that stuff.

In ECL logic you had to deal with faster than light problems in the wire. You take a wire off a pin, and you'd wrap it around the board four times and then you'd put it onto the pin next to it, so you could get the correct clock delays, right, speed of light was an issue. So, it was interesting stuff.

And the first software job I had also started out as a hardware job as we were doing robotic systems. We were using an old Motorola computer. It was 68000 if you can remember back that far. There were no compilers for the 68000. Motorola's user tech support was just miserable. And unlike Intel, they did not provide compilers, they didn't provide any kind of development environment, it was just nothing.

So, the first real software that I had to write was a compiler for the Motorola 68000. It was a C compiler for the Motorola 68000. The second piece of software I had to write was an entire operating system to run this robot. So, I sort of jumped in full blast.

Mary Poppendieck: Yes, so, in TI 990, I was programming, no compiler, no nothing either, but I just programmed in the assembly language instead of bothering with the compiler.

Allen Holub: Well, I did a bunch of that, too. I think one of my first experiences with what I thought of is production code, which taught me that production code wasn't what I thought it was. There was a problem with one of these robots.

So, my boss at the time said, "You know, look at the code, figure out what's wrong." And I looked at the code, and it was this massive assembly language. Inside the assembly language, there were three branches, each of which had a go-to branch to the middle of one of the other branches, right? You had three loops, and then a branch from here to there, right in the middle. Then, that fell through to the second one. And then, it branched down to the third one into a different like...

It probably took me a week to figure out 100 lines of assembly language. It was hellish. That certainly taught me a lot about how things were not supposed to be done, right? The guy who wrote this was really proud of it. He was saying, "Oh, this is...it's elegant, and it's fast. And it's small."

And I'm going, "None of these matters, you know, sitting here is the poor guy who had to deal with it," right? I'm saying to myself that none of these matters, right? None of these, like standard-engineering-at-the-time criteria as to what makes good software counted, because it took me, two days to figure this thing out and to unroll it.

Once I unrolled it, it wasn't much bigger. All of the criteria that this guy was so proud of we're still there, but you could read it. Being able to read it was an important thing, I think. So, I guess that was the first lesson that I learned was dealing with all this badly-written-by-engineer code.

I guess the other side of that is you should never trust a hardware engineer to write software is that we all see that. We see that in Logitech equipment all the time, right? All these hardware engineers writing software.

Mary Poppendieck:  Yes, indeed. I had a Logitech clicker that I had to throw out because it had a button on there, that if I was giving a talk, and you push that button, it would bring you back to the beginning of the talk.

Allen Holub: Yes, I know that problem.

Mary Poppendieck: Yes, there's no way to defeat it. And everybody who ever had that clicker in the hand, eventually, during every single talk, eventually hit it once. 

Allen Holub: There is a way to defeat it. I wrestled with that same problem.

Mary Poppendieck: Really?

Recommended talk: War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile • Allen Holub • GOTO 2020

Allen Holub: On the Mac, at least you can run Karabiner. What Karabiner does is maps anything into anything. So, it was capturing that keystroke and turning it into something that was reasonable.

Mary Poppendieck: I just threw it out. Any other comments about his discovery?

Bernd Rücker: I just thought of what he said, a hardware engineer is a bad programmer. I remember one professor I had at the university. He was really proud of doing these assembler classes. That was a time when Java was a thing so, the assembler was kind of, "Okay, you have to learn the basics." But it was not the thing.

He did an exam with a self-modifying assembler program. I was kind of...and he was proud of that exercise. At one point in time in the class, he told us as he thought about it. He thinks assembler is kind of object-oriented because you have code and the data like close together, almost like. That was my experience with hardware engineering. So, I'm in doubt as well.

Mary Poppendieck: So, you want to tell us about your first job and what you wish you knew?

Bernd’s story: From graphic cards to automated processes

Bernd Rücker: Oh, happy to. So, I started later than all the stories here. I started programming when I was a kid. I did a lot of games and a couple of other things.

During high school, I did my first professional program. A friend of mine did graphic cards business. At that point in time, you could mod or overclock graphic cards to get more out of it if you're into gaming because power was quite expensive. Mining was not yet a thing, it was really for gaming. And you could test that. So, he tested these graphic cards to sell them if they can't be overclocked like this.

That turned out into a pretty successful business, actually. And he did that with piles of graphic cards in his home and with emails like sending around and stuff. He said, "Hey, look, this has to be better." I thought "Yes, sure this should be better."

Then, we basically dived into what I would... Looking at it now it would be really like analyzing the process, the business processes that are going on "Okay, what do you have to do for returned goods? Okay. What do you have to send to the customer? What tests do you have to do and what order and what sequence?"

We tried to automate the essential parts to basically remove the pile of stuff there, the customers calling in, sending emails, "Hey, what's with my graphic cards and all that kind of things."

That turned out into developing, I would say, a lean ECM system, at that point in time, like really handling all the things in Java, automating kind of the core processes. What I just learned last year, I think, it's still in production. That was 20 years ago. So, that surprised me quite a bit. I wouldn't have given that a year.I mean, I learned a lot. So, I don't regret anything there. I learned a lot about how to structure such a system.

A lot of things I know now from dimension design, for example, what's a domain? What's the boundary between the domains? How do I layer that? How do I automate a process that also spans multiple of these boundaries? But it was quite hard, at that point in time. Now, I'm totally in process automation and workflow engine.

So, at that point in time, the technology was pretty heavy, not developer-friendly, very expensive, big vendor-driven. It was really hard to use, actually. That was quite frustrating. Aso, technology bias. I mean, Java Enterprise, Java Beans 2, at that time, that was a technology which didn't really help. I mean, it was more...

Mary Poppendieck: Is there anything that if you'd known it when you started, you would have been better off?

Bernd Rücker: I mean, not really, to be honest. I'm pretty happy with what the result was.  I think I struggled a lot with technology at that time. And that's the big thing I see now is that we really improved with the technology. I mean, it took me a long time to learn a lot of things like how to structure the domain, how to do the layering, how to automate a process, how this everything connects together because there was not much I could find at that point in time like knowledge-wise.

Recommended talk: Balancing Choreography and Orchestration • Bernd Rücker • GOTO 2020

There were a lot of EDP books or technology books or probably architecture books, but very abstract. I couldn't really map that to my problem. I think that's much better now. All things are written now around all of these topics and would have helped me a lot.

Mary Poppendieck: Okay. Any other questions for him? So, who'd like to tell another story, another origin? So first? There you go, Aino.

Aino Vonge Corry's story: Learning your own way

Aino Vonge Corry: Yep.

Mary Poppendieck: Did I get your name wrong?

Aino Vonge Corry: Yes, well, anything works. Ino like I know, you know, Ino.

Mary Poppendieck: Got it. 

Aino Vonge Corry:  So, I didn't program as a child. I wanted to be a mathematician. I just stumbled upon programming at the university. I completely fell in love with it. I loved how I could control the computer, so that was wonderful.

I did a lot of programming during my university and Ph.D., but it was sandbox projects. I wasn’t, put into a big legacy system. So, when I got out in the industry that's what happened. I got put out into a big legacy system.

What I didn't know at the time was that if there's something you don't know something about, you can actually learn it. It's not just because you're stupid. Because what happened was that, of course, I couldn't just understand that legacy system without any help. So, there was one of my colleagues who sort of said things to me that made me sit in the toilet and cry every day at work.

That meant that what I did after that was just like Java server pages and stuff like that because I completely lost the motivation for programming. I did that for some years. After that, I've only been learning new languages just on my own.

What I wished I'd known then was that it's okay not to know everything and it's okay to ask for help. It's okay to feel stupid. Other people should be okay with giving help and not laughing and not ridiculing and actually trying to mentor because most things can be learned. And I think that's an important thing that I've learned over the years.

I didn't understand it, theoretically, until about 15 years later, unfortunately, where I came back to my university to do research on how you teach computer science. Then, I learned a lot about how you learn, how the brain learns, and how you teach in the best way to support different kinds of brains. Then, I learned, "Aha. So, that's why. I wasn't actually stupid. I just perhaps learn in a different way than this colleague learned."

So, I wish I had known that and I'm trying the best I can to tell people that they're not stupid, they just probably learn in a different way.

Mary Poppendieck: I wish you hadn't got stuck with such a colleague.

Aino Vonge Corry: Well, that's life, huh?

Mary Poppendieck: Yes, I started out life as a mathematician too because they didn't actually have computers when I was a kid. I got a master's degree in math because the computer science stuff was not actually there yet.

The guys at Bell Labs were being sent to Math, to get Math degrees in order to learn how to program. So, I definitely sympathize with the Math part. And they're so much similar I always thought...

Aino Vonge Corry: Yes, in some kind of way.

Mary Poppendieck:: ...thinking mathematically and thinking about software.

Aino Vonge Corry: And solving problems, right? Trying to identify the problem and solving it based on experience and good ideas and guessing and a little bit of magic.

Mary Poppendieck: Right. And being wrong a few times.

Aino Vonge Corry: Yes.

Mike Amundsen: Yes, I was wrong a lot. I mean, I was very lucky that I was in an environment where it was a very supportive group of people. Things didn't work the way I told them it was going to work. Things didn't work the way that they had expected.

And rather than give me a hard time about it, they said, "This isn't quite right." I mean, I was just very lucky to be in a group where they literally said just that, "Well, this isn't quite right." Instead of...

Aino Vonge Corry: That would have been better.

Mike Amundsen: Right? Yeah, right? So, I was very, very lucky because I had to stumble quite a bit in the beginning. So, I learned early on a supportive environment of people who are focused on how to help you succeed rather than claiming that you failed really made a super difference for me. I was very, very, very lucky because not all my friends are.

Aino Vonge Corry: By then, it seems to me that... Now, I'm teaching at university, many of the people coming out of there, even though they've been programming their whole life, they really believe that they have to come out there and hit the ground running and be superheroes from day one. I tried to tell them, you're not going to make any value the first time. That is okay, that's the same for everybody. Take your time.

I rewrote the same software later in my life. I rewrote the same software three or four times before I got it right. I was a living example of a second system theory. I was like, "Oh, I learned so much in doing this."

Aino Vonge Corry: Yes, the second time.

Mike Amundsen: "This is all wrong Let's do this again."

Mary Poppendieck: Start it all over again. Right

Recommended talk: The Importance of Laughter • Aino Vonge Corry • GOTO 2019

Allen Holub: I'm actually shocked that you think you actually got it right. I don't think I wrote a piece of software that I got right.

Mike Amundsen: There you go.

Mary Poppendieck: Probably, there's no such thing as right.

Stefan Tilkov: That was good, actually, very good.

Mary Poppendieck: So, who would like to...? We got a couple more stories to go here.

Uncle Bob’s story: the passion you invest

Uncle Bob Martin: Oh, I'll go.

Mary Poppendieck: Okay, Bob.

Uncle Bob Martin: I'm in competition with you, Mary.

Mary Poppendieck: All right.

Uncle Bob Martin: Let me see if I can show you this. Right, somebody has to come up with a year earlier than Mary. So, this was the first computer that my mother gave to me when I was 12 years old. That would have been 1964.

You can see it's got three bits, three ones and zeros, right, three little flip flops, and little rods here and gates. You could program this thing by putting little soda straws on these little pegs here. You've got a nice three-bit finite state machine. I just inhaled this machine.

My father got me... Let's see if I can dig this up here. Oh, here it is. Let's see if I can get it. My father got me a number of books. One of the books he got me was this one. I don't even know what the copyright date on this is.

Mary Poppendieck: What does it say again?

Uncle Bob Martin "Boolean Algebra, 1964."

Mary Poppendieck:  That's what I...

Uncle Bob Martin: Boolean algebra and I inhaled that book. Again, this is like at age 12. I didn't get a job until I was 18. And that was at a company near my house where I got involved with doing a little COBOL and oh, God, that was awful. I bailed out of that as quickly as I could. And the company bought a Varian 620. This is in the early days of minicomputers when every company in the world was making their own minicomputers and Varian radio was making their own and we bought one of theirs.

What I and two of my high school buddies did was to write for them, in assembly language, a real-time, timesharing union accounting system that would control a set of terminals that stretched from our Northern suburb into the end of the city of Chicago, where the local 705 Truckers Union would type in all of the union dues and all of the jobs, and we would send reports back to their ASR 35 teletypes.

Mary Poppendieck: Right, on this little computer?

Uncle Bob Martin: Yes, this one. No, this is the one it was working on. The Varian 620/F was a 16-bit machine, it had 64k of the core. Eventually, they made that RAM but, you know, this was back in the...this would have been 1970, probably.

This was a labor of about a year of very long weeks and long weekends. And the one thing that I did not know then that I wished I'd known then, and I do know now, is that it is completely stupid to work 80-hour weeks.

Mary Poppendieck: Ah, yeah. It got you so far. So, did you ever get anything working?

Uncle Bob Martin: Oh, yes, it worked just fine. We got it all to work and then we all quit.

Mary Poppendieck: Good luck with that then.

Uncle Bob Martin:  All at once, all three of us. We walked out the door. Then, six months later, I had to go beg for my job back. I had to work for a little while on... So, another thing that I wish I had known back then that I did not know is don't quit in anger. And don't quit suddenly.

Aino Vonge Corry: Yes, don't slam a door.

Uncle Bob Martin:  Never walk out the door.

Aino Vonge Corry: Yes, never slam a door.

Uncle Bob Martin: Yes, you might have to go back.: Because you may have to go back.

Mary Poppendieck: Like you...

Allen Holub: I actually had the opposite experience of that though. I had a boss once. I was objecting to something he was ordering us to do because it was just not right. he said, "I'm the boss. You're the flunky. When I say jump, you jump." And I just jumped right out the door and was quite happy with that right as walk down the hall. There was another company there and I went working for them. It was easy.

Allen Holub: So, if we're gonna do a show and tell.

Uncle Bob Martin: Is that all right?

Allen Holub: Here you go, Bob, this is a sheet of IBM 360 and 65 core memory.

Uncle Bob Martin: Boo.

Allen Holub: There's 1K of memory on here. And some poor person went blind making this with like tiny little ferrite cores, you can't see that on the camera.

Recommended talk: The Scribe's Oath • Robert "Uncle Bob" Martin • GOTO 2017

Uncle Bob Martin:  Oh, you've got a bigger chip that I think I did.

Mary Poppendieck: Look at that.

Allen Holub: My core is bigger than your core.

Mary Poppendieck: You have this 64k memory computer. In 1972, I published an article in IEEE Computer Magazine about how to take a minicomputer with 32k of memory, core memory, and expand it to 64k of core memory by using a spare toggle bit.

Allen Holub: No kidding.

Mary Poppendieck: And it was the assessment of the minicomputers at the time. This crazy one that you've never heard of because there were only 10 were built was the one that I figured out how to double the memory by using an added bit.

Uncle Bob Martin:  Very good. That's very cool.

Mary Poppendieck: So, Stefan would you like to go next?

Stefan Tilkov’s story: You don’t know everything when you are starting out

Stefan Tilkov: I can start if you want to. So when I got my first programming job, I was the hero. This was fantastic. This was great. Because among a group of people who were supposed to develop their very first C++ program, I, as a fresh graduate, was the only one who knew even the remotest tiniest bit about this language because I had fiddled with it. So, I felt fantastic. It was awesome.

I was this young, 23-year-old person and everybody had to ask me for advice. All these seasoned engineers didn't know what to do with this language. They had decided to do things in an object-oriented way because the salesperson had sold the project that way to the client because that was a new way. But nobody knew anything about it. They were all C programmers and a Fortran programmer and some database programs, but nobody knew anything about object orientation.

So, what they had done before I arrived, as they've already done the object-oriented design, which essentially meant that they had like these two large binders filled with pages. Every page had an object, it was an alphabetized list, you know, from A to Z, all the objects. This was design. It was so great. It actually reminds me a lot of many modern microservices architectures. But that was funny.

We started to actually draw some pictures. That was something like maybe five or six or seven years before UML or before the Three Amigos joined forces. So, I think we use some SA, SD

So, while I felt so great about myself, which was really nice for me, personally, maybe not so much for the project, I got a lot of trust. Then, people basically started believing everything I said, which was a horrible mistake, because I told them, "Well, the way to build software the right way to build software is, especially when you're doing the object-oriented fashion, is to start with the base libraries."

That was my idea. You know you build this fantastic machinery. That'll take some time, it's totally normal that for the first six or eight months of the projects, you don't see anything moving around, you don't deal with any actual customer data, or you know, build an actual user interface for anybody. It's perfectly normal to build all these libraries with fancy class hierarchies and get all these things done because once that's done, things are going to be super-fast.

So, everybody believed me for about eight months. And then, we found out that things weren't really that fast. In fact, everything was much slower than it was before when they simply had whatever text UI built on directly hitting the database. There was a much faster way. It would have probably been a better way to build that project.

So, essentially, after eight months, we threw everything away, started from scratch, second time was a lot better. 

I think, what I wished somebody had told me back then is that it's a good idea to not get overly ambitious and not fool yourself. And to build something, and put it in front of actual end-users a little earlier than instead of believing that you will have this fantastic machinery built, and then everything is going to be great.

Interestingly enough, this has served me as something, maybe my first war story, and I found this extremely useful because it's the best kind of reuse that you will ever discover in this industry, which just people make the same mistakes over and over again. I don't know how many generic thing machines I've seen in the last 30 years, it's just everywhere, everybody makes those mistakes. So, it would have been nice to not do it. And that it better be...

Aino Vonge Corry: It makes your job as a consultant very easy that people make the same mistakes, I've noticed. "Oh, that's an interesting problem."

Stefan Tilkov: I don't why.

Aino Vonge Corry: Let me think, hard to solve that.

Stefan Tilkov: I may seem wise. I was just wrong first. That was, you know, I made a mistake. I know that I knew, that's all.

Mary Poppendieck: You're not supposed to reveal secrets like that.

Aino Vonge Corry: Sorry, we can edit it out. Can't we? This is not the Aino you're looking for.

Mike Amundsen: That's right. Exactly right.

Mary Poppendieck: So, most of the programming I did was for machines, not people. Because I did engineering computing, I controlled machines or things like that with minicomputers. And the thing is, most of the time, I was working in an engineering office, not the IT department.

The engineers, when they were working on something they'd never done before, kind of automatically tried stuff out a lot, and expected to learn gradually and tested their stuff on whatever pieces of equipment they could get their hands on kind of immediately.

So, to me, this was, of course, the way Windows software. It took a lot of years, you know, the first thing that I put in a manufacturing plant was a big presses control system. But it had all these discrete components because the presses control system can die at any time. And so, any given piece could be completely taken out, and then put back in again, without disturbing the whole thing, because that's the way big equipment works.

I could make a change. I could have it running within five minutes because that's the way you did with big press control systems. It took me forever to discover that in business computing, you build things, and you compile things, and you don't run them right away. You have to take all of this time to build and compile and test.

It took me a very long time to understand what people were talking about when they talked about this process of the test and build and all that sort of stuff. Whereas we build something, we pulled it out, we plugged it in again, and we did it hot, even when it was in a manufacturing plant. That's the way engineers worked. When, I discovered that, you know, lots of software people worked different ways. I was pretty astonished.

Mike Amundsen: Pretty astonished.

Mary Poppendieck: Pretty astonished.

Recommended talk: "Good Enough" Architecture • Stefan Tilkov • GOTO 2019

The agile story

Mike Amundsen:  It was the same for me too because I had conveniently avoided learning and teaching, training. I just did the same thing. I remember working in a system where I knew we had to fix a bug every single day, and you couldn't drop the system. So, we were designing it so that I could change something without breaking anything else. We knew that we were gonna have to swap parts out.

So, early on, what I didn't realize are these things that now have names like Agile and Lean and all these other things. We were just trying to make sure we solve the customer's problem today. Didn't really pay attention to what I was doing.

Allen Holub: I was thinking about that the other day, though, because the first job I worked in would be an Agile shop by today's standards. So Agile is just a gleam.

Mary Poppendieck: Is that not true for most of us?

Allen Holub:: It was like everybody was relaxed. We didn't have a boss telling us what to do. We all work collaboratively. It was like Agile, right? It's the way it's supposed to work.

Mike Amundsen: Right. And Mary, I thought you were...

Allen Holub: I was kinda shocked the first time I had an experience with people working in a big corporation where they were not allowed to work that way. I just, I couldn't get it. Right? It just seems so ineffective what they were doing.

Aino Vonge Corry: Yes. I've had discussions with people in small startups where they said, "No, we're not doing agile, we hate Agile." And I was, "Do a talk together every day?" "Yes, of course." "Do you talk to the customer?" "Yes, we do. "Can you change the software based on what feedback you get?" "Yes, of course, that would be stupid otherwise." Okay, you're not Agile. Yeah.

Mary Poppendieck: Who needs Agile, right?

Aino Vonge Corry: It's because Agile in some cultures is a bad word. Right?

Allen Holub: Yes, you know, and we were even doing it in the hardware. Back in the day, it was a wire wrap. So, you could like, adjust the hardware as we do. So, it worked out.

I was sort of not really a boss because I was just a kid. But people were paying attention to me when I told them what to do. I forced one of the hardware engineers to write a device driver for his own hardware. And that made huge changes within the organization.

Mary Poppendieck: That's called a unit test for your hardware, right?

Allen Holub: That's a unit test. That's exactly, right, Mary.

Bernd Rücker: That's great. I would agree that we all know all these Agile paradigms and the advantages, but what I'm still kind of negatively amazed is, if I get into big corporations, you very often see processes that are absolutely not Agile.

And you talk about these, like I use "Accelerate," the book, and all these DevOps reports based on that a lot to make a case for developing more Agile. It's still a thing. It's still something you have to talk about in a lot of organizations. That puzzles me a lot, to be honest.

GOTO Recommended talks:

Allen Holub: I was thinking the other day about speed, right? Because everybody talks about speed, speed, speed. Sutherland is to blame for that focus, right? Faster, doing every faster.

Mike Amundsen: Hyper productivity.

Allen Holub: But I go into shops, and it's like they said, "We need to do things faster." And then they categorically and absolutely reject everything they could do that would speed them up, right?

Stefan Tilkov: "No, that's not that way."

Uncle Bob Martin: What is that, right?

Stefan Tilkov: "Not that way."

Mary Poppendieck: None of that.

Uncle Bob Martin: No, you're wrong.

Mary Poppendieck: Somehow, I think people who start out, you know, the very first programmers were scientists and engineers and mathematicians, and a few musicians threw in there. And the way you think is not, "Let's gather everything together and do a great big thing." It's, "Let's do one thing at a time and try it out." That's the way you design hardware. That's the way you build pieces of equipment.

Software is just a sort of another add-on. Somehow, the aversion to making mistakes grew up Since I'm biased, and I'm an engineering programmer, I always thought of those business programmers, they just didn't know how to do things. Who would ever want to do business programming when you could do engineering programming where you can actually, look at a piece of equipment and watch it move and say, "I did that. I made that work."

Allen Holub: Well, even that, you know, is that...

Mary Poppendieck: Like the Hubble Telescope.

Allen Holub:: ...on the robotic side, I had to talk to people on the business side who are writing programs that interface with our robots. I remember once I wrote down a specification, I said, "Here's the way the hardware is gonna work. The software doesn't exist yet. But here's the way it's going to work."

The business guys we're going, "Woo, I've never seen anything like that before. This is really useful." So, they had never seen a specification before, which makes me wonder what they were doing. You know, it's kind of...

Mary Poppendieck: Yes. They were doing what Mike did when he started his first job. Right, Mike?

Mike Amundsen: I guess so, yeah. Exactly.

Allen Holub: But they were real programmers, right? We were just a hardware guy. They were the real programmers. And if they didn't know what they were doing, then nobody knows what they're doing.

What made software developers stop looking at what they did?

Aino Vonge Corry: What killed it, then? What made software developers stop looking at what they did all the time and inspect and adapt? What made them stop was the large deployment cycles, was that developed...?

Allen Holub: I don't think they have stopped. I've never stopped. You know, I started that way. The companies I've worked with, they do that like it's called a startup. That's the way they work, right?

Aino Vonge Corry: Everybody in this room is doing it right. But those who stopped, why did they stop?

Allen Holub: I don't think they stopped. I don't think they ever started. I think the big corporations that we all wrestle with all the time as consultants started out thinking about factories. They thought that you design and build software the same way you build stuff in a factory, it's an assembly line. And they just never questioned that.

It's not like they did it right and they stopped. It's that those particular companies started that way. They started thinking that way, and they can't break out of that way of thinking.

Meanwhile, all the startups are not thinking that way because they didn't have that same experience. Right? So, it's much easier for them to be Agile in the real sense of the word because they haven't...there's not all these forces getting them to think in an assembly line, as an assembly line. Where I just think, they're just not thinking that way.

Uncle Bob Martin: Imagine that crazy growth that's been going on amongst programmers. How many programmers are there in the world today? How many were there in 1965?

Mary Poppendieck: True enough.

Uncle Bob Martin: And the difference is many, many orders of magnitude. There was this moment in the 1970s when all of the original older programmers kind of started to retire. And in from the universities came a flood of 20-year-old idiots, like me. We didn't know how to heck to do any of this stuff. And the business world was there with open arms saying, "My God, do we need programmers. Come on in, you can write COBOL, you can do all this work."

All the original programmers who really had worked out this Agile thing were gone. They were gone away. They were retiring. And the software world went through this 30-year-upheaval of trying to figure out how the devil to get this to work. It took us 30 years, it took us till about 1995 to actually start getting a clue again.

Aino Vonge Corry: So, they were programming assembly line, they did a little bit and passed it on and did a little bit of passed it on and didn't know what it was used for and...

GOTO Greatest Hits

Uncle Bob Martin: Think of just the wild growth. You know, every five years, there are twice as many programmers as there were before. There's nobody to teach anybody. There's no way to get the knowledge to move through this huge cohort of people. So, literally, every five years we're starting over again trying to...

Mary Poppendieck: And there's nobody to just sort of being the coach, the manager. So, it turns out, these people are working for somebody who has no clue what they're doing. Like, no clue at all. And so, all it can do is impose rules and processes because they don't have any clue how to coach these young folks.

Mike Amundsen: Yeah, but it's not the cluelessness that's the problem. It's being convinced that you do know when you don't.

Mary Poppendieck: Well, there you go. Yep.

Mike Amundsen: They are clueless, but they're not open to learning new ways of working. Right. That's probably the biggest problem with the big corporations I go into is people have this idea that this is the way business works. Of course, you've got line managers. Of course, you've got roadmaps and upfront plans, and there's no other option, this is the way it works.

They just can't imagine alternatives. And trying to explain an alternative, they look at you like you're crazy. And, you know, how do they do it?

Mary Poppendieck: Except, they don't do that typically in their core line of business. If they're insurance companies, they do very Agile insurance products. If they're banks, they do very Agile banking products. If they do manufacturing, they do very rapidly changes to manufacturing lines.

But this stuff called software, there's nobody in the leadership of the organization that gets it, so they pawn it off to cost centers. And say, "You guys figure that out, and you know, keep your costs down because we need you, but..." You don't see in their core line of business the same approach as used to be in the software area.

Uncle Bob Martin: I did a job for Fireman's Fund, which is just north of years ago now. And they really did it right. They didn't know what they were doing. They just did it instinctively. So, they had like seven or eight teams working on this. They were they're redoing their insurance adjusting software. They pulled their seven best insurance adjusters off the line and assign them to the teams for a year so that they could have an onsite expert telling them what to build. They just did that instinctively. It was it worked out well.

Mary Poppendieck: Yes, because they were messing with their core product. And when an organization messes with its core product, it knows how to build that.

Bernd Rücker: I'm not sure if I totally agree, especially insurances and banks, I think the understanding that they are basically a tech company nowadays, that changed over the last 5 to 10 years. I think understanding changed, it's just simply pretty hard to be able to change such a big organization. At the same time, it's really hard to get good people because everybody needs developers, we just learned we don't have enough, dependent on the point in time you're looking at that.

That means you don't have enough people. And you have to change the whole organization. You have to live in that digital transformation world, which is kind of scary, in a way as well.

So, I think there's a lot coming together. And even if you have that understanding now, and I think a lot of organizations have, it's simply hard to get to where they want to get to. I think this transformation takes a while.

Of course, that's much easier for a startup, which starts from scratch, to have this enthusiasm, which probably attracts good developers, at least a handful, to do something. That's hard for a large organization, just to be fair to them.

Mary Poppendieck: Well, large organizations t were born before the founders understood anything about computers. But if you look at the big, large tech organizations, they have not had to go through that. Because they were born right.

Mike Amundsen: Hmm. Wellborn.

Allen Holub: Yes, I'm not sure I agree with that. You know, I look at Facebook, and I look at Uber, and I'm not very impressed...

Mary Poppendieck:  True enough.

Allen Holub: ...at what they're doing. You know, there's a lot of stuff wrong there. Right, a lot of which has to do with the personalities, I think, of the people that founded the companies, and I...

Bernd Rücker: But I think I could agree with the point that they are born with, let's say, digital natives in mind. That's different from an insurance company founded 100 years ago living with a different mindset for quite a long time, having the legacy now. That's, yeah, I do see that point. I just wanted to be fair.

I mean, I'm not a huge fan of big organizations. I've worked at Lufthansa for quite a bit during my university. I'm not sure if I should say that on recording, but I was done with big corporations. I was like, "No, never again."

Mary Poppendieck:  Never again.

Bernd Rücker: So, I learned that, at least at that point in time. But I think we also have to be fair with them, it's pretty hard to be a large organization and to adjust the way of working and to make software development part of your heart of the organization, that's a huge change. And of course, that doesn't happen overnight.

Uncle Bob Martin: Has anyone seen it happen ever?

Mary Poppendieck:  Seen what happened ever?

Uncle Bob Martin: A large corporation steeped in the old ways become Agile?

Allen Holub: No.

Mary Poppendieck: Well, I worked at a large corporation. The software I did there was always Agile. But I did not work in the IT department, which was clearly not. I worked in the engineering world. Right from the start, our practices and the way we approach things were always Agile. It was a great big company.

But that was the way engineering was done. It wasn't the fact that it was a big company, it was the fact that engineering was a core competency. We built very fancy novel big raw goods processes, and instrumented them, and did it for a living and had very good engineers that have been doing it for decades. They had practices that were very Agile.

The fact that I happen to do part of that job in code made no difference. That was just, you know, another piece of engineering, you wrote code, because, you know, you had to do less wiring now.

Uncle Bob Martin: And that was not a transition, right? That you were transforming the organization.

Mary Poppendieck: No, there was no transition.

Uncle Bob Martin:  That part, this was before that way.

Mary Poppendieck: In the IT department, I don't even know if they've transitioned now, but they were very much the other way.

Allen Holub: I have seen that happen in pieces. In other words, you can apply this strangler pattern to a corporation, right? They can spin-off this little skunkworks thing, right, and just leave it alone and let it do something, and then they look at it and they go, "Oh, gosh, that's more profitable than anything else we're doing."

Gradually, everything moves over to these little skunkworks projects,s and the rotten core in the middle just kind of dies and then sloughs off as it rots. That's a big company becoming Agile by becoming small companies.

Aino Vonge Corry: Yes, it's in one of those microservices. That's what I was about to say that I haven't seen a full transformation either, but I've definitely seen, like, you carve, take pieces out of a monolith, and make a few microservices, and they can live. And perhaps the rest of the monolith has to stay, right?

It's a bit like the same where some of the teams are actually able to have that content with the future users that they can show and tell and inspect and adapt and go back and have that. I mean, that's what I think when I think Agile, I mean, inspect and adapt, right? And try this and try this.

Some have the possibility to do that. But I also see sometimes that for them to actually do that, they have to lie sometimes to the upper limit. So, what I do is that I encourage them to lie. I know it's not good, and idealistically I shouldn't. But if that means that they can do great software for a subset of the customers, I think that's better. I haven't seen a full transformation. I've only seen that like carving out microservices.

Uncle Bob Martin: I've seen that to where you get parts of an organization that will transform themselves and becomes Agile. Over the years, what I've noticed is that it's not stable. They either will revert back, or they will separate and become separate companies.

Mary Poppendieck: Ok, it reminds me of Kuhn's "Structure of Scientific Revolutions." Where he says, a paradigm shift happens when some young upstarts come and have new ideas, and the old mental model doesn't work anymore, and it becomes more and more fragile. Then you divide into model defenders and model skeptics. The only way to get rid of the old model is for the model defenders to die or to retire. 

I think that it's the mental model of software. Those who are the model defenders are not going to go away, but eventually, they will retire. How's that?

Aino Vonge Corry Agile by death, is that what you're saying?

Mary Poppendieck: What?

Aino Vonge Corry Agile by death?

Mary Poppendieck: Yes. That's what it takes for revolutions to happen.

Aino Vonge Corry No tweets about that.

Allen Holub: Some of the companies I've worked with, the people who were on top, we're not defending the old ways, they were just completely clueless. They weren't doing anything really. And whether they were present or not kind of didn't matter, in some ways. You know, so they weren't pushing back much.

In this particular company, I'm thinking of, there was one group, a bunch of teams got together and formed kind of a Mongo team. They literally built a wall around themselves. They went and got a bunch of whiteboards, and they built a wall around the area that they were working in. And they wouldn't let people without being invited.

They wouldn't let managers in, they wouldn't let anybody in. It was like a black box with respect to the rest of the organization. But they were more effective than any other team in the company. So, they were left alone. They said, "No, everybody who's afraid..."

All these clueless guys saying, "I don't know what they're doing, but it's working. So, let's leave them alone and let them work." And that worked pretty well, you know, at least in terms of getting stuff out the door.

Mary Poppendieck: Was it permanent?

Allen Holub: That's a good question.

Mary Poppendieck: Is it like this?

Allen Holub: It was permanent for the three or four years that I had any contact with the company, I don't know if they're still doing it. It's been a few years now. And I don't know if they're still doing it. But it was permanent for quite a while by our standards of permanence, right? At least three or four years, right.

Mary Poppendieck: Stefan, I think I interrupted you, right? Or you interrupted...You had something to say?

Stefan Tilkov: I wanted to say that. I second thought that it's typically the organization's resistance rather than processes or technologies or methods or anything. Just you know, the organization is set up in a certain way. Adopting this new paradigm would mean the organization would have to change. What if that's in conflict with the interests of the people who are in power at various levels, then it'll never, it just can't work. It doesn't matter what the change is that we're talking about here, if the organization is built around the old paradigm, then that's the problem.

Mary Poppendieck: Yes, because the metrics and the expectations flow from the top.

Mike Amundsen:: That's right. Yes

Mary Poppendieck:: And if they're not going to change them, the organization's gonna have to die.

Mike Amundsen: Yes. Or some portion of it, right? That's kind of what we said before. I remember being told once, I was helping in a budgeting process, and I could tell this team was squirreling money away from the corporate head like they were inventing things and you know, and I was the one who was helping them.

I said, "You sure you want to do this?" And what I was told is, "In order to be successful in this organization, you have to have a little larceny in you." That was, it's kind of like Allen's deal, right? What they were doing is they were building a little shell and nice little protective shell, where when something goes wrong, because of this budgeting process was another one of these big upfront kinds of things, you know, six months later, when something unexpected happens, I'll have a little nest egg. I can go ahead and solve this problem.

So, what happens is people create all sorts of weird adaptive behavior, right? I can't get this part of the organization to move. So, I'll hoard things, or I'll rearrange things, or I'll order all the walls to be built, whatever, in order to protect my team, protect my group to carry water from... I think we've probably all seen versions of this kind of organizational behavior as well, right? It's just the idea of like, how do I survive this kind of thing?

Mary Poppendieck:  Well, actually, as I recall, as a technology manager in an engineering department, not an engineering department, but a lab, like a product building department, we were expected to do that. That was corporate culture, squirrel away some money so that you can... If you're a manager, and you don't have a back pocket where you can fund little projects, then you're not doing your job.

That was corporate culture. That's how 3M invented many of its new products. So, nothing wrong with that, if you're going to have a crazy budgeting process, then you need to know how to game it.

Mike Amundsen: 3M is a great example of a major blunder to start, right? Their whole history was, they thought they were going to be mining one thing. And it turns out, they bought a bunch of lands and it's mining something else. "Oh, what will we do?"

Mary Poppendieck: Yes

Mike Amundsen: Yeah, it was brilliant. And it affects their whole long-term culture, right? It's really...

Mary Poppendieck: The long-term culture, at least, as long as I was there was that. There was such a thing as a budget, and you probably shouldn't go over it. But that didn't mean it had to be an honest budget.

Mike Amundsen:: There you go.

Mary Poppendieck:  And if you're a smart manager, you got enough money to fund what you needed to do. And you were judged on whether or not you did what you needed to do, not how the heck the money was spent.

Allen Holub: That's right, you're judged on results. There you go.

Mary Poppendieck: And there was not the same concept of slack. I worked for a very good control engineer, who told me, who was the manager of our control department, control engineering department, and he said to me once, "You know, I always keep my top two engineers unassigned to projects. So, then when there's an emergency, I have an expert to send in."

Allen Holub: There you go.

Mary Poppendieck: He didn't have to account for that. That was the way it was expected to do his job. Because if a plant went down because something was wrong with the control system, you had like hours before you started costing the company tons of money. So, if you were the head of the control engineering department, and you didn't have your top two engineers sort of ready and waiting to jump on an airplane or help out any junior engineers that needed it, then you weren't doing your job.

It wasn't like, "Is everybody busy?" It was, "Could you, within the way you manage things, solve the problems that needed to be solved as fast as they needed to be solved?"

I think, unfortunately, we're gonna have to wrap up, but does anybody have any sort of final words, comments?

Allen Holub: This has been great.

Mike Amundsen: I think it's cool.

Uncle Bob Martin: Oh, Thank you.

Bernd Rucker: Yes. Thank you. It's been a lot of fun.