The Need for Wisdom

29. January 2017 Uncategorized 0

Myopic Software Development

I know nothing about software development!

I have developed software professionally for 17 years. And yet, I know nothing about software development.

I have contributed to an application that was used literally across the world (and quite possibly on all 7 contents). And yet, I know nothing about software development.

I have worked at a fortune 50 company. I was the number 2 developer at two different start-ups. Yet, I know nothing about software development.

I teach classes via Pluralsight, and speak at conferences on writing software. Yet, I know nothing about software.

Am displaying false humility? Am I using hyperbole? How can it be that after 17 years of writing software (and really, I wrote my first piece of software 31 years ago) that I know nothing about software?

Because in the past 17 years, I’ve worked on a lot of projects, written (and deleted) a lot of code. Learned new paradigms like smart pointers, interfaces, vectors & maps, TDD, dependency injection. But I still don’t know anything about software development.

In that 17 years I’ve focused exclusively on applications. Here’s a partial list of things in the software realm that I’ve never worked on or written:

Operating Systems
Drivers
Libraries
Frameworks
Embedded Software
Real-time software
Security algorithms
Databases
Graphics
Communication software
Physics engines
Artificial intelligence
Distributed systems

I have 17 years of professional software development experience. I’m finding more and more that the people I meet and run into haven’t been writing software for that long, or at least not as a career. And so I start to feel like I’ve been around a while, but in reality, I don’t know anything about software development. I know about the software I’ve written. I can still tell you about data link traffic from my time at Caterpillar. I can tell you about performance profiling an app and then rewriting it to increase performance by 10x. I can tell you about writing super fast queries so that people using Salesgenie can get their sales leads. I can tell you about applications I’ve written. But I haven’t begun to scratch the surface of software development.

Where’s This Coming From?

This past week I made a tweet about wanting to see more wisdom in software development.

As I thought more about it, I thought it probably deserved more than a tweet to lay out what I was thinking.

It all started when I was listening to Software Engineering Radio and they had an episode about errors. At the time, I didn’t know who Gerald Weinberg was. I had never heard of him, and initially wasn’t sure that an episode about errors would really be that exciting to me. But as I listened, I realized that Mr. Weinberg has 50+ years of experience as a software engineer (he got his PhD in 1963, which was 54 years ago.) He had worked on the Mercury missions. He had worked with computers that had vacuum tubes instead of transistors.

Sidebar:

My dad got his BSEE in 1968 and if I remember the stories correctly, he was the first class they taught transistors to. I believe he also learned vacuum tubes. By the time I graduated from the same institution 32 years later I made it four years without learning anything about vacuum tubes.

All of that is to say that that Mr. Weinberg has likely seen a lot of different things in his days as a software engineer. The C programming language didn’t come around until 1972, almost a decade AFTER he obtained his PhD. C++ followed 11 years later. In that time, the industry has seen both OOP and Functional Programming paradigms (fun fact: despite it’s recent rise in popularity, functional and “functional-flavored” languages date back to the 1950s: https://en.wikipedia.org/wiki/Functional_programming#History ). During the time that Mr. Weinberg has been an engineer, the industry has gone from mainframes, to dumb terminals, to thick clients, to web applications, and lots of other various deployments as well (e.g. embedded and mobile.) In a sense, in that time, we’ve gone from a client-server relationship (terminals & mainframes) to hosted (desktop) applications and back to client-server applications(websites.) Each major change was brought about for very good reasons, and addressed specific issues that people were having.

Frame of Mind

As I thought of this, I was struck by something. Here’s someone that I had never heard of, but someone I should be listening to. Is he infallible? No, of course not. Nobody is. But does he know more about software engineering than me? Without a doubt.

It was also around this time that I had finally been exposed to the Redux pattern with JavaScript with any detail. I’d heard it talked about at work some and I was even on a project that kinda-sorta used it, but I hadn’t really looked at it. As I typically do, I try to find parallels to other things I’ve done. That way I can say “It’s kind of like ____” and someone can answer “Yes, but it’s slightly different because ____.” As I was sitting in the meeting learning about Redux it hit me: this sounded a lot like event sourcing, or at least my understanding of event sourcing. Once I made that connection I was able to ask some slightly less dumb questions.

I didn’t want to make a declarative statement that Redux was similar to event sourcing, because I didn’t really understand either. So I did some searching and I saw other people also make that claim, which made me feel a little better. I also saw someone refute the claim, which was good because that should expose me to why it’s not like event sourcing and help me understand it better. However, I was quickly frustrated because one objector said redux couldn’t be influenced by event sourcing, because the creator of redux didn’t know about event sourcing before he created redux. To me, that’s not a very valid argument. At best it means he didn’t steal event sourcing, but that doesn’t say anything about their similarity. For an example of how something can be similar without being stolen, check out Leibniz–Newton calculus controversy, where both worked independently and yet came up with something similarly despised by college freshman across the world.

It is these type of analogies that I see when I make statements like “Angular 1.x is the new VB6.” I’m not cutting down Angular 1.x. I do not like writing VB6 code now, in 2017. But in the late 90s and early 2000s, it was actually quite enjoyable. It became a gateway for line of business applications to be written. In a very real sense, a large part of the application industry is still reaping the rewards of VB6 today. And I see Angular 1.x as being similar. It is a gateway for a lot of people to start writing JavaScript applications. I imagine that years from now there will still be some Angular 1.x applications doing mission critical software for companies. If you’re still writing software in a decade, you might even be lucky enough to be rewriting an Angular application into something else.

Applying Wisdom

As I thought more about this, I came up with the dichotomy of exclusively focusing on intelligence vs wisdom and opted for more wisdom. What I meant by that was, too often we in the software community get caught up with what’s new, and knowing the next thing. There are quite a few blog posts written about JavaScript Fatigue, as people feel like they need to continually learn something new in order to stay relevant.

And too often that new things is touted as a never-seen-before technology. But often, that’s simply not the case. Take Single Page Applications as an example. What was the motive for SPAs? Some of the motivations were:

Everyone has a browser
That browser isn’t doing as much as it could be. If we were to leverage the power of a client computer, then it would be possible to take a load off the server.
If the server only had to deliver a JSON array or JSON object, then the browser could figure out where to place that data on the screen.

Watch what happens if we replace the word browser with desktop pc.

Everyone has a desktop
That desktop isn’t doing nearly as much processing as it could be.
If the server only had to deliver data to the desktop, the desktop could process the data and send it back

Was the advent of SPAs a good change? I think so. Was it totally unique? No, but it might look like that if your only experience with programming was something like ASP.NET MVC or Webforms both of which required the server to do a lot of heavy lifting and left the browser to simply handle button clicks and styling.

We, as an industry, could learn a lot from people that have already gone through similar transitions in application development. Too often, though, we are either too naive to realize that there even are people that have gone through a transition like this, or we’re arrogant to the point that we think this case is something totally different.

Advances in the Industry

Supposedly new paradigms are created and advanced in the industry. As I referenced above, if you were to read Twitter and attend some conferences, you might think that Functional Programming is a brand new invention set to take the world by storm. We have Elixir, and Elm, and Haskell keeps popping its head up. There blog posts and libraries set to help you make JavaScript more functional. Yet it’s been around longer than most current developers have been alive.

As much as I enjoy Elixir, I think it would be more profitable for me to hear from engineers that have been developing for 30, 40 or even 50 years as to the strengths and weaknesses of both OOP and FP. My guess is, that people that have used both might prefer one, but don’t see it as the be-all-end-all solution to software development.

I’m afraid we’re not learning from the past. Sure, there are more younger developers than there are developers that have 50+ years of experience. And I’m not advocating that anyone with more than 25 years of software development experience should be blindly trusted. But if we face reality, we’ll see that we’re going to be losing those experienced engineers at a quick rate, before too long. We’ve already lost 1/2 of the Kerrigan and Ritchie combo. Two guys who have no doubt thought way more about software than I likely ever will.

Same Ol’ Same Ol’

What does it mean to focus on wisdom in software? As I was thinking about this post, I thought about how it’s very similar to another series I did almost 6 years ago. Back then I documented some of my thoughts on What is a Software Engineer. It was a 6 part series that covered various aspects of things I thought a software engineer should be able to do. The six items were

The tl;dr of that series could be: “Has wisdom, and writes code.”

Wisdom means learning from those who went before us. It means evaluating systems and seeing trade-offs. It means thinking about what has happened and what could happen. It means taking the good from a working system, and working to improve the bad. And it means recognizing that nobody today has all the answers.

A Non-Software Example

I’ll leave you with a story from earlier in my life. It dates back about 14 years ago. At the time I was doing pulpit supply in central Illinois. For those unfamiliar with the term, when a pastor is out of town, or a church (particularly a small church) doesn’t have a pastor, there are a group of preachers that they will call and ask them to fill in. I was working full time as an engineer, but for a couple years I’d preach 10-12 Sundays a year. One Sunday I was preaching at the church I regularly attended. It was a traditional church in which after the sermon the pastor stood by the door and shook everyone’s hand on the way out.

As I was standing there after preaching a deacon named Bill Sadler came by. Bill was around 80 at the time. He had spent his entire career working in the factories at Caterpillar. Bill was a very grandfatherly kind of man. He’d joke with you, and love you, and just talk to you. He shook my hand. Then he said “You’ve got the preaching thing down. But remember, they don’t care how much you know until they know how much you care.” Bill had never been a preacher. So it would have been easy for me to dismiss this statement and say “Bah, what does he know?” But Bill had worked and served and ministered to people in that church. He knew what it was like to comfort people who lost their loved ones. There was a lot of wisdom that Bill imparted to me. He never talked to me about how to interpret the Bible, how to construct a sermon, biblical or systematic theology, or how to parse a Greek verb. But that sentence has had quite a great impact on my life.

I think the same can be said about the software industry. There are developers/engineers/programmers that have never seen the problem I’m trying to solve. They might not have ever written JavaScript, but they have a lot of wisdom to share from their experience. And I would be wise to listen.

After all, I know nothing about software development!