The Intraview

I have interviewed for jobs in the IT field for quite a few years now. There is a similarity to the questions, yet I have interviewed for a number of different types of jobs in both management and technical capacities. To save some time in the future I thought it was a good idea to sit down with my evil twin brother, Dr. Kelly Flanagin, Bf.D. (Organizational Psychology, Stanford, 1985), and get the basics out of the way once and for all.

NOTE: Kelly is not really my twin brother. We are close in age, and we look a lot alike, but we are not twins. He is also not really evil.

Think of this as the long awaited intraview. It has been reprinted with kind permission of Intellectual Exhaust magazine. These are excepts. To read the full article, see the April 2016 issue, pp 17-29, and 59. If you want, you can jump to directly to conversation about methodologies, management, getting older as a programmer, object oriented programming, and even design.

NEW CONTENT ALERT: An eleventh axiom of software development has been discovered. See the article on the home page.

-------- quoted content follows ---------

K: It is good to finally sit down with you outside of the mirror. Say 'hi' to our mother, OK?

me: Thank you, I will. Today I am feeling rather specular, myself.

K: I will start with the question everyone asks: What is your favorite programming language?

me: The snarky response is "the one I am currently getting paid to use," which at the moment is Python.

K: Would that be Python 2 or Python 3?

me: I am not familiar with Python 2.

K: You are in a snarky mood today, bro. So what do you like about Python?

me: It may be the first programming language that has been developed for ease of debugging, and given that I have been known to pre-bug and even re-bug my code, that is a strong argument in favor of Python. I like the tools, the modularity, and the lack of an abrasive straightjacket when it comes to OOP.

K: I thought you had published an article or two about OOP. It sounds like you do not like it so much now?

me: Like, not like, does not really enter into it, but I admit to having made a good living in the 1990s by understanding OOP. Along with other software religions --- Agile springs to mind --- OOP gets in the way of software development.

People seem to decide ahead of time that they are going to use OOP in their code, and it simply makes no sense to think that it is appropriate for every problem. I knew a guy quite a few years ago who tried to rewrite a financial transaction system with OOP, and after four years and fifty million dollars down the drain it was ridiculed as the Ken Starr project because he had nothing to show for it.

K: How can you possibly say that? A lot of people swear by using Agile to design, and OOP to build and test.

me: I have worked on projects that succeeded and ones that bombed. It seems that in cases of success, people have a very hard time finding anything wrong with the conditions that were present when they succeeded. You know, if you met your wife on OkCupid, you probably think online dating works for everyone, and you recommend it to all your friends. When programmers were using punched cards they probably thanked IBM for making possible the one-line-change.

And when they fail, it is never their technological religion that fails. I have heard people say "Well, we were just not doing Agile 'right,'" or they might say "We did not have our OO hierarchies correct."

K: So how do you develop software?

me: When I start, I like to meet the end users in person. I had a good experience when I started at Capital One Bank. My assigned task was to develop a method to queue inbound calls in the network along with a small amount of data. I spent a day in the call-center with the people who answer the phones, and it shaped my perspective on the work to be done much more than studying a pile of specs.

K: Great, but that is not what I meant by software development. How about something more concrete.

me: The fact you do not see meeting with the users as software devlopment says a lot. But then, you are a journalist rather than a software developer.

While I agree with Zed Shaw that we really should work on getting better at programming, software development is not a succession of drive-by activities where you send one person out to get the requirements, and someone else to design, and someone else to code, and someone else to test.

You are probably one of those people who thinks someone else needs to write your documentation, too. Am I right?

K: Watch it. I'm your brother. But I want to get back to the design-develop-debug-deploy cycle. How do you design software?

me: I look to non-software systems for ideas. There is no reason to think that we are so good at developing software that we never need to "look around." Then I doodle for a while. I try to find some representation of the solution that will fit on a single sheet of paper, or perhaps two sheets, and then I like to write a little code to get a grip on the parts that I do not have a good working idea for already.

K: No UML?

me: No. Instead of the idea that every problem is different, I have found that there are only about ten types of problems and a larger variety of solutions. Finding out which of the ten types of problems yours resembles ... is the first order of business.

K: There is a rumour that you have set of commandments, or axioms, or something for developing software. Something a little light on details, and thereby you avoid the m-word (methodology). Care to share?

me: I don't mind telling you. I have been misquoted a lot, so here they are:

1. Always evaluate build versus buy, but without your thumb on the scales.
2. All tools are amplifiers for whatever is already going on. It's why tools don't seem to work in poor organizations -- they make things worse.
3. Cutting corners always costs money.
4. In programming, the skill of the programmer is more important than things like the programming language.
5. At least a couple of people on the team should know computer science.
6. Understanding the problem is a pre-requisite to solving it.
7. All teams, good ones and bad ones, are cults of personality around the key people.
8. The designer (I really hate the word architect as a noun or as a verb) should be around for the whole project.
9. Without exception, systems that work are testable, modular, independent of the tools and languages used, and most importantly -- elegant.
10. For most procedural things like source code management, it is more important that they get done, than it is exactly how they are done.

Now, ten commandments have a familiar ring to a certain subset of the population, so I have added two more:

11. If a system must be reliable, it must be testable by a process that is demonstrably simpler than the system as a whole.

12. You always run out of desk space before you run out of money.

K: How can you build software without a methodology?

me: *(sneezing fit)* I did not say that, did I? *(coughing)*

K: Are you OK?

me: Yes, it is forsythia pollen. I think I must be allergic to them. To answer your question, the fact that I reliably get the work done indicates that there must be a method, if not a methodology, at work.

I look at it this way: Every hour of the working day you have to make choices about how to get the work done on schedule. Every hour that is spent on one thing, could be spent on something else instead. It bothers me that there are conferences and conferred titles associated with the formal methodologies, and there is less time spent on becoming better at programming and the other nuts-and-bolts of software development.

As a manager, I would hate to look around my department and find that everyone was a certified Scrum Nut Buster and no one had bothered to learn how to best use the programming language at hand in the environment we have. To make the problem worse, people act like learning a new programming language is too large an amount of work to be considered, but the same people will happily embrace the idea of a learning curve that is several projects long for a methodology.

K: If you are referring to Agile, I think the term is *Scrum Master*.

me: Oh, yes. I should know that.

K: I think you *do* know it, and you are just being rude. Would you care to speculate on why methodologies are so popular?

me: Sure, I love to speculate, but they are popular mainly because a lot of money changes hands. People just don't want to admit it.

My reasons...

1. Methodologies give you something to "do" instead of programming, and most people are not too keen on programming.
2. There are very few consequences to being wrong, compared with the way the compiler points out every mistake you have made, and there is no way to argue with the compiler.
3. There is a general feeling among managers that when it comes to ass-covering, it is better to say you have some methodology in place. When you fail it is somehow evidence that you tried, even though it is really evidence that you hired the wrong people or perhaps did not have people doing the right things.

K: But I want to get away from methodologies. Can you give me an example of something where OOP is a bad idea.

me: (brief pause) This may not be quite what you are looking for, but it is a good example of a case where OOP does not add anything except a pat on the back for having used it.

I am writing some software now that sends real time messages, SMS and email, to concerned people when errors happen. So I wrote a function cleverly named send_message() that does just that. It checks the addresses, resolves phone numbers to SMS gateways, and then calls the appropriate system `mail` function with validated data.

In OOP, this would be put into a class. You would create it, attach the message, and have a line of code that like mymailer.send(). In a strict OOP landscape, the mailer class would probably inherit from a few base classes, and that alone would make it difficult to use the same chunk of code in another, unrelated application.

K: Let's move on to management, shall we?

me: I have to be careful here; I voluntarily returned to being a worker bee, and I now have a boss who might read this.

K: I don't intend to only ask softball questions, but I cannot make you answer, so we're even on that point. Let's start at the top. How should an IT department be managed?

me: The more successful places I have worked had a division of responsibilities between a CTO and a CIO. Those may not have been the job titles, but the job functions were separated like this: The CTO evaluated technologies, vendors, programming standards, and whatever else might have an impact on the company. The CIO took this information and made decisions about what to do.

In most cases the CTO had the CIO for a boss, although one would hope the CTO would be given some independence. After all, if you know the answer as the CIO, there is not much point in asking the question.

In less successful operations there is no CTO. No one is really at the top of the technology pile, and the CIO ... it seems all organizations have a CIO ... is simply presented with a bunch of data. Given that most CIOs are not overly technical people, they run the risk of being most highly influenced by the person to whom they talked right around 5PM.

So technology direction becomes a shouting match, and the first person to talk loses. Once people figure out the rules, they stop talking.

K: What about bringing in consultants to help make the big choices?

me: It [bringing in consultant] is something I have never understood. Many companies spend big bucks on a CIO, and then the CIO turns around and hires high dollar consultants to do the very things [most people] would think were well within the CIO's abilities. One way that the employees see these things is that the CIO either cannot do the job (very unlikely), or the CIO does not trust the people who work in the organization to contribute information --- another reason a CTO is a good idea, and the right person to handle the consultancy. Management consultants contribute to the perception that everything is a drive-by level of involvement, even if it is not.

K: That's the second time you have used the phrase 'drive-by' in this interview. What about the argument that the consultants bring an independent viewpoint?

me: I think it is very unlikely that any but the most morally conscientious consultants really give an unbiased recommendation to the person who is paying the bill. Another reason to have a CTO buffer the information -- the CTO will still be around after the consultants leave.

K: How do consultants effect the workplace for people farther down the food chain?

me: At HP (Hewlett Packard Labs) we called this the consultant glow. We had a number of the more capable but less listened to engineers leave the lab and go to work for staffing firms. They would get rehired as consultants, and everyone in management would suddenly accept the same recommendations that had been tabled just a few months before.

It is not too long before the whole organization is dominated by policies sourced from consultants who are not around to suffer the consequences.

In general, if there is no technical hierarchy, the technical people stop talking outside of one or two close people who are trusted. It becomes hard to build trust, and even some effort must be put into maintaining the little trust that there is.

K: Considering your apparently strong feelings about it, why did you decide to get out of management and go back to programming?

me: More than anything, I reached a point where I had enough of everything except for "time," and I thought spending my more mature years as a mature programmer was the best thing to do. Of course, it might not be the right choice, but I have a few years left to change my mind. (laughter)

I am the best programmer I have worked with in the last fifteen years, and I think I have a positive effect on the people I work around. The era of the functional manager seems to be over, and outside of very small companies the responsibilities are usually too diffuse in the management jobs.

K: Do you think management is 'non-functional?'

me: (extends middle finger) That's not what I meant by functional manager. Functional management refers to the manager who runs the team. The team works together to make the manager successful, and all that stuff like matrix management cannot work if my people are working for someone else. If you . . . .

----------- a fragment of page 26 was sent in by a reader! ---------------

me: [missing text] . . . hasn't been directed at me, or I didn't notice. That's not to say that it does not exist. My reading of posts on Quora indicates that some people as young as 40 think they are being turned down because of age.

K: You are what . . ? Almost 60?

me: I gotta love the way you pretend not to know. I am 58.

K: Why do you think so many IT professionals who are 40 and up think agism is happening?

me: I think people perceive stick-in-the-mud-ism regardless of age. If (potential) co-workers think you are dragging your feet and you happen to have a lot of grey hair, they attribute your behavior to something they can see.

I have worked with people who don't want to learn a new programming language, don't want to learn how to use new tools, nor even work with new operating systems. They do themselves no favors and they do me no favors by being such Luddites.

Now I have to be careful here. I heard a joke once that Condoleezza Rice couldn't run for President because the nation is not ready for the first anti-Black Black President. I sound like I am an anti-senior citizen almost senior citizen. That's not it at all. The attractive part of being in IT is the constant "newness." Nothing is what it used to be. If you get to a point in your career where you cease to enjoy learning, then it is probably time to do something else.

K: If people leave IT, do you think they go on to be-[come] . . .

----------- end of the fragment from page 26 ------------

----------- end quoted material ------------

NOTE: Unfortunately the remainder of the Intraview was corrupted because of water damage to my only copy of the original, and the use of water soluble ink by the cheap people who published the magazine. We are currently searching for other copies of the magazine with the missing pages intact. When and if better copies are recovered, the new material will be (re)printed here.

Please send JPGs or PNGs of any fragments to me+intraview@georgeflanagin.com. Thank you.