Why Management? Making a Difference

Every engineer who’s made the transition to manager has a different decision story. Some get promoted up through the ranks and stay at the same company. Some move into it fresh. Some do the transition all at once. Some do a slow roll; they’re both a manager and an engineer for some transitional period. I think it’s helpful to hear about others decisions to move into full time management. It might help dispel the feeling that you’re alone, that you’re the only one who’s been through it.

This is my story.

When I was hired it was as a Supervisor-slash-Engineer. My time was to be spent about 50/50 between the two roles. It never really worked out that way. I was repeatedly pulled away from coding because of my managerial duties that only I could do. Repeatedly, the deadlines of my management work would be in direct conflict with my coding work. When I went to my manager to help prioritize, the coding always moved to someone else. After all, I was the only one who could do the management work.

I was approaching my one-year anniversary as a manager when this all came to a head.

Setting the Stage

I was ramping up to do my first performance reviews and write my first business case for quarterly planning (back when we did those things). I was adding new functionality to our newly rewritten application for our big year end push. I wasn’t sure how to implement this at all, but I was determined to figure it out. It was a stressful time, but I was getting through. I was determined that this time my management work wouldn’t get in the way of me being the one to implement this feature.

It was a Monday morning a couple of weeks before Thanksgiving. My Architect asked me to chat in the conference room. Well this can’t be good, I thought. Yep, he’s giving notice. I’m unsurprised but It still hits me in the gut. I’ve never been through this. I try to communicate something that says how much I appreciate his work without making it sound like I’m laying on a guilt trip. I have no idea if I succeeded. We go to tell my boss. “Fuck,” he said. That was my sentiment too. He just said it out loud. You see, our newly rewritten application was my Architect’s baby. He had written a huge portion of the code by himself. He knew it inside and out and no one else did. There was voodoo magic back there.


Much of the next week was consumed by managing the various administrative tasks that happen when an employee leaves: coming up with a plan to divide up his work among the team, getting authorization to fill his position, deciding what that would be, and getting a job description written and posted. It was quite a whirlwind.

In Over My Head

The next Monday I had my 1:1 with my manager. Instead of being my normal, energetic self, I was hunched over. When he asked me how I was doing, I hung my head. “I can’t do it,” I said. I was in way, way over my head. I was falling further behind on all of my other work–you know, the work I was barely keeping up with before all of this happened.

I should give some perspective here. I have a long history of doing more than is possible. I have gone through many times in my life when I had too many balls in the air and couldn’t let any of them drop. I have gone through many times that put me off the charts on those little stress tests. The first time was when I transitioned from middle school to high school, my sister was an exchange student for a year, and my parents got a divorce. I’ve gone to school full time, transferred schools, had a part time job, had a young child and asked for a divorce. I’ve graduated from college, got kicked out of my living arrangement and had my child go spend the summer with his father. I raised a child with a disability, with an adversarial ex, while not making enough to put food on the table. In fact, going through times of massive change in lots of parts of my life is a common theme. I’m used to doing a lot with not a lot of help.

This, all of this, it was too much.

My manager did what a good manager does. He got a complete list of all of the balls I had in the air. He said my first responsibility was exiting my Architect, getting my team in the right place and getting a replacement for him. He ran interference with HR on the performance reviews and took over the business case. The coding got moved to someone else. I was relieved. I could breathe.

The situation passed. I worked through it.

However, through all of it I had a thought that I couldn’t dismiss. My coding had moved to someone else. Again. Again the work that was supposed to be half of my time got moved to someone else. I had only had time to finish coding one sizable piece of work in a year. One. I started a lot of others; I just never finished them.
I thought about it and talked with my partner a lot. It was clear. I had to choose.

Fortunately, by this time the choice was obvious to me.

Making My Choice

Back in my manager’s office for our 1:1. I’m talking with him about the fallout from the previous few weeks. We’d had this type of conversation before after each time that he had to prioritize away my coding work. Each time I had said that I could work it out. I could juggle the coding and the management. Each time he was supportive of my choice. This time he told me about a point in his life when his employer had told him that he had to choose between architecture and management. He quit rather than decide because he wasn’t ready to decide yet. He was supportive of giving me the time I needed to choose.

I told him I appreciated the time and the support and I had already made my choice. He was surprised, but I pushed ahead. I choose management. Yes, I can code. I’m good at it. I enjoy it. But lots of people can code well. I can also manage. I’m good at it. I enjoy it. Very few people do that well.
I felt a kind of responsibility to do this thing well that so many do badly.

Making a Difference

As a manager, I showed my team how to approach problems differently. I coached them and help them grow. I had the authority to do things that I hadn’t had before. I solved problems before they hit the team. I developed relationships with my peers in the rest of the organization that changed my team’s work for the better. As a manager I make a positive difference in people’s work lives.

There are many managers in IT that don’t know how to manage. That’s unfortunate, because there are a lot of resources out there. I worked hard to find those resources. I was also lucky; I had great guidance and support when I started as a lead and in this first management role. I owe thanks to many people who helped me with this transition. They gave me the space, confidence and experiences to really see the difference I could make.

I hope to pay that forward with the same abundance in which I received it.

Why Management? I’m Really Not a Control Freak

I was at a conference last year that had an “unconference” session on “How not to be a Pointy Haired Boss”.

Many of my peers said, “No way do I want to go into management.”

It’s pretty common wisdom that managers in IT suck.

So you’re a manager of software engineers, developers, programmers, what ever else you want to call them. Maybe you’ve heard, or even said, some of the following:

  • “No way I want to go into management.”
  • “Managers in IT suck.“
  • “Management is a necessary evil.”
  • “I don’t want to have control over other people’s lives.”
  • “Engineers don’t make good managers.”  (I just overheard this one at my coffee shop.)

I’ve heard or even said some of these things. And then I became a manager.

I started out my management career half manager, half software engineer. This proved to be more difficult than I thought. At best I would only have an hour or two each day available for coding – and that was non-contiguous. With increasing frequency and severity, management deadlines directly conflicted with project deadlines. My own manager was supportive; he would prioritize my work. Most of the time, that meant the coding work went to someone else because I was the only one who could do the managerial work. At the end of the first year, I knew I needed to choose. I could have delayed the choice. I had support to delay the choice. I could have chosen to give up the management work and go down the architecture path. After all, when I was hired that was what I thought I wanted to do. There was just one little problem with all of that.

I like management.

There. I said it. I said something that is unfathomable to many – especially engineers.

I like being a manager.

There. I said it again. How could I like management? Am I a control freak? Well, a bit. I’ve been accused of being CDO before. I’ve even said it about myself more than a few times. But this is the weird part: I have never felt less in control than when I became a manager. That might seem like a contradiction, but hear read me out.

Management != Control

When I started out as a manager, I learned that the most effective managers don’t operate from their role power, i.e. “I can fire you.” They lead with influence instead of control. This kind of leading is about inspiration; it’s about making the team more important than yourself. It’s about communication and relationships. That’s not a position with a ton of control, believe me. I started reading more and more about leadership, empowerment and servant leadership. It was daunting.

Then I learned that relationships with my peers across the organization were going to be essential to doing half of what I wanted to get done. My team was isolated from the rest of the organization. I was shut out of the planning and strategy process, or included only at the last minute. I started using lunch as a means of getting to know my peers and sharing my vision with them.

I made mistakes…. Okay, I made a lot of mistakes. I made a few really big mistakes. I learned later that your first promotion to manager is the hardest. I believe it. I was highly regarded by my peers as an engineer. I had put in my 10,000 hours. Now I had a few hundred hours, tops. While hours aren’t everything, certainly my lack of hours was a significant factor in my lack of skill.  I don’t know anything that makes me feel less in control than feeling like I don’t know what I’m doing. For several months I wasn’t sure I had made the right choice.

I struggled making the transition from doer to coordinator of doers. I struggled figuring out how to relate to people in roles that were the one I just left. I struggled learning how much to communicate when. Sometimes I struggled just with what to communicate. I struggled as my calendar spiraled out of control. I struggled finding a calm within the storm and time to myself. I struggled with not being in control.

Sometimes stubbornness is a strength that we call perseverance.

Refusing to be Peter

I became obsessed with being the perfect manager. Honestly, I’m really lucky to have a life partner that knows me and understands or I might be single now too.

You see, if I’m going to do something, I’m going to do it well. Very well. I refused to be an example of the Peter Principle. So I absorbed as much as I could as quickly as possible. I took a class on supervision. I started working with a professional coach. I read blogs. I asked questions of my manager. Every opportunity I had, I learned more about managing people – especially engineers. I became a little obsessed—that’s the CDO again. I neglected a lot of other things along the way. That cost me dearly. I’ve learned a lot in the process.

Of course, one of the biggest things I learned was that I like management. Not the firing or disciplining part. Only sociopaths like that.[1] I love being in a role where I had the influence to really make change. I love building relationships that make it possible to really get things done. I love creating a vision, helping other people understand it, shepherding it through and watching it come to fruition. I love coaching and mentoring my team. I love seeing them grow to greater potential. Managing has some major upsides.

Paying It Forward

A good friend of mine encouraged me to start blogging. I was reluctant.  Then articles persuading engineers to write showed up in my twitter feed. I ran across a video on vulnerability. I’m sure I was just especially attuned to the messages. Still, I thought “What would I do if I wasn’t afraid?” I would write a blog about leading in IT and software engineering in particular. I would probably include more than a few on iterative, collaborative software development. I’ve started acquiring quite a list of resources. I’ll be sharing those too.

Here are my thoughts, opinions, questions and rants. I hope you find them as useful to read as I do writing them.

1. I am not a psychologist, I use this term for effect.


One thing I’ve learned in my years as a developer is that I am more eager to go to work, and am more invested in doing the best job I can, when I feel an emotional connection to my team and my employers.

That connection can take the form of friendship, or loyalty, or empathy, but if it’s there, I do better.

Knowing this about myself, I’ve always made an effort to build that connection to my team and to people in other teams throughout my company. I’m naturally a gregarious, goofy guy (sometimes to excess) and I try to use those tendencies to make friends. I also get to understand the business, what it’s doing, how all the pieces fit together and how each team contributes to the goal. And then for me, doing my part becomes more important because I know how what I do impacts everyone else.

I also know that I’ve worked for people at some of my jobs that have encouraged and facilitated this, either deliberately, opportunistically, or instinctively, because they understand that value.

Being in the lead role, it’s important I understand that I, now, also should take the time to foster that connection in my team. I don’t know if it’s in me to inspire loyalty, but even if it’s not, I think I’m not too bad at building a little friendship and empathy amongst my team. But beyond that, it’s important for me to help the people on my team get a grasp of the things that leads like myself have to get to understand implicitly, namely, the various parts of the company and how they work togther, how the work of our team impacts all those other teams, and how those teams impact our own.

By encouraging my own team to build those emotional connections, I encourage them to become more invested in their jobs. And if I succeed, I reap the twin rewards of lower turnover and greater productivity — as well as making some friends along the way.

The counterpoint to all this is an experience I’ve had many times as well — a company where those connections are not encouraged and are not valued. We’ve all been there, whether it takes the form of a boss who’s all stick and no carrot, a team that is every-man-for-himself, or a team so isolated from the rest of the company that they don’t care about anything that doesn’t directly impact them. Think on your experiences in places like this. Did you work harder, or not? Did you have an easier or harder time getting out of bed in the morning? Were you more or less willing to stay late to get the job done?

Yeah, me too.

So it’s really a no-brainer which kind of culture I want to foster in my team. So it’s just a matter of learning how.


Some people seem to think that by impressing a sense of sufficient urgency that the impossible can be made possible.

Let’s consider the hypothetical scenario where you’re at home, and you live a 30 minute drive from work when traffic is good. Today, traffic is not good.

Your boss calls you in a panic and says you have to be at work in 15 minutes. You tell him you’ll head out immediately but it’s really unlikely you’ll be there in less than 30.

Your boss tells you that you need to be at work in 15 minutes or the company will lose its most important client. You tell him you’re already on your way, but it’ll still be 30 minutes, even if you speed and weave through traffic.

Your boss tells you that you need to be at work in 15 minutes or the company will go under, and it will be all your fault. You’re upset, and angry, but you tell him there’s no way you can be there in time.

So you break several traffic laws and finally rush into work 25 minutes later, your boss blames you for failing to come to work on time and causing the demise of the company. And you’re silently plotting how to murder your boss without leaving any forensic evidence.

The entire scenario is absurd, of course, yet this is an all too common scenario of software development: The business owner sets a development schedule that’s laughably unrealistic, and when the development lead pushes back, the business owner behaves as if he believes he can make the project complete on schedule by imparting a sufficient sense of urgency to the development team.

It won’t work, of course; the dev team may, of course, work in panic mode for the duration of the project and try in futility to make the deadline, and then when they fail they will be so exhausted and burned out that they will be useless as developers for weeks afterwards, but that means the project fails and the company has a completely demoralized dev team that’s probably been updating their resumes.

Project owners need to listen to their development teams when they say that the project deadline is far too soon. Instead of trying to crack the whip, project owners need to work with the development lead and project manager to figure out the alternative. That alternative may be a reduced list of features, a revised deadline, the addition of resources, or some combination of the three.

But setting an arbitrary deadline and offering only urgency and consequences to the development team for failing to meet it, apart from violating the Fourth Rule of Development, can seriously damage the morale, and by extension the value and effectivenes, of the development team.

It’s about the team

First, a note:

I’ve been rethinking, due to feedback from friends and family, how I present the content of this trifle of a blog. I’ve been writing directly about my experiences while keeping the name of my company, and the names of my coworkers, obfuscated using nicknames and euphemisms. However, that isn’t really obfuscated enough to keep me out of trouble should this blog ever get connected to me by the wrong people. So, henceforth, I shall talk about my learnings without directly relating my experiences at work, so there will be no issue. You can make up your own story about what experiences I had which led me to be taught or reminded of whatever I’m imparting with my blog entries. Experiences outside of work, well, those I may continue to discuss directly as discretion permits.


Now then.

One quality of a development team, or indeed any team working together, that is often undervalued is how well the members of the team interact on a personal level. Teams which are comprised of even exceptionally talented people who do not have any affinity for one another will not work exceptionally well together. Teams of much more modest talent who have a strong affinity for one another will become more than the sum of their parts. It’s not hard to imagine circumstances where a less talented team with more mutual affinity will be more productive with better results than a more talented but less cohesive team.

A lot of employers understand that personal affinity is important; they interview for new hires by evaluating technical skill but also how well they believe the candidate’s personality will integrate with the team and/or the company. They call this ‘cultural fit’ usually, but I think they often don’t consider the full implications of how well personalities fit one another, and in particular the magic that can happen where a team comes together comprised of people who develop strong professional and personal bonds with one another.

Here’s a question: How many times have you seen a candidate for a job show strong technical qualifications, but is iffy culturally, and get hired despite misgivings over the cultural fit? Here’s another: How many times have you seen a candidate for a job who presents a superb cultural fit, but is more iffy in technical qualifications, and get hired anyway?

I bet most people in the development world would answer these questions somewhere between “occasionally” and “frequently”, and somewhere between “never” and “almost never” respectively. For me it’s “occasionally” and “never”. But let’s think about this, and consider that this is exactly the opposite of the way things should be.

Skills can be taught. Someone entering a job with some technical deficiencies can be trained to grow into the job. Anyone with development experience has witnessed this — most of us, in fact, have lived it. We learn, adapt, and grow to meet the needs of our jobs even if we don’t start with the necessary skills. If we can’t do that, we’re probably not in the right line of work. We can also learn ‘soft skills’ – leadership skills, communication skills, organization, etc. But we can’t learn to have a different personality.

Oh, sure, we can learn to fake it; learn to pretend that the Nerf gun war that breaks out among the development team isn’t an annoyance and is fun; learn to have detailed conversations about international cuisine like it’s interesting; learn to geek out about the latest episode of Doctor Who or The Walking Dead as if we are interested in either — but if you don’t love shooting your buddies with foam darts, if you don’t relish new dining experiences, or if you don’t giggle inside at the phrase ‘wibbly wobbly, timey wimey’, you aren’t going to change. And fundamentally, you’re never going to build that connection to people who geek out in ways that you don’t.

So why is it that hiring decisions are often made on the principle that trainable qualifications are more valuable than untrainable qualifications?

In the area where I live, positions available for highly skilled developers are much more numerous than developers are available to fill those positions. My friend and colleague Red, whom I’m now calling Mojo (because she prefers Mojo) has said that the best solution is to find a strong cultural fit who’s below the desired skill level, hire that candidate, and invest in that developer through mentoring and training. This course of action makes even greater sense in light of the above.

So with all that in mind, imagine that rare confluence of a great group of developers, designers, project people and leadership who have developed that strong affinity, mutual respect, and friendship with one another. This is a group of people who not only want to be successful as individuals but who want to see each other succeed as well. They look forward to seeing one another and collaborating together.

How much harder and with how much more dedication will this group of people work on a given project when they have that mutual bond motivating them? And what will they be able to accomplish together?

I’d sure as hell like to find out.


One of the things I need to keep in mind as a lead is that the list of things I need to know in order to be effective has grown. It’s not just the details of development, design and architecture, along with a baseline knowledge of requirements gathering, project management and QA, but also things like business strategy, budgets and, as proved important today, vendor agreements.

We’ve been looking at changing the web hosting provider for our new site since a little before I came on board. When I joined, it was among my first tasks to compare our current provider with our potential new provider — to assess value of the services for the price.

Part of what I did was review the contracts — in particular, the uptime and support guarantees, and made note of what each was offering. (As the company has tens of millions of dollars a year in sales, every hour of downtime is a potential loss of thousands of dollars — during prime time, tens of thousands.) And by making note of these facts, I was able to recoup a significant chunk of change for the company today.

As it happens, this morning we found the staging site — the one hosted by our current provider — was down. It was down because the load balancer*, which is entirely in the provider’s control, was failing. This halted much of our development. Amazingly, this premium web hosting provider to which we pay several thousand dollars a month was unable to have the site back online by the end of the day, and we since learned it was down much of the weekend before that.

Much frustration ensued, including a push to switch us over to the new provider ASAP. But towards the end of the day, I mentioned to the CEO this little detail of the contract with the provider: For every hour of downtime, we are entitled to be credited 5% of our monthly contract fees. It’s also important to note that the contract does not specify that this credit caps at 100%.

The dollar signs appeared over the CEO’s eyes when he brought up the contract and confirmed that information. Gleefully he asked me to put in a request with that provider for a refund — and forwarded me the pertinent clause of the contract.

I just earned my pay for the month, I think. And I also earned a strong measure of the confidence of my CEO, which is very important to achieving my goals for the company. And I also had an important lesson of being a lead reinforced. I’m going to remember the importance of keeping apprised of the details of many things beyond the development process itself.

*If you don’t know what a load balancer is, it’s a server at the front end of the web server cluster that routes incoming traffic evenly between the web servers so that the servers handle roughly equivalent “load” of that traffic. Basically, if it stops working, your entire site fails.


A story from the past

At a company someone I know worked at, he was part of the dev team. The dev team had a great culture. They were interested in their own success, the success of the team, and the success of other teams within the company. They cared about doing their jobs right.

At this same company, there was an IT team. This IT team was not particularly invested in the success the company, and didn’t show any real signs about being concerned with the quality of their own output. They were often obstacles, rather than partners, in the dev’s team efforts to do good work, and they displayed attitudes of aloofness, indifference, and self-interest.

In a nutshell, IT and development had two distinct and very different cultures.

In many companies, IT and development have some crossover, as some development projects have IT impacts and vice versa. This company was no exception. So the dev team often found themselves grumbling amongst each other at IT’s obduracy.

Dev was hiring, and found a guy who impressed everyone, who had a skillset that Dev really needed, but who didn’t have the skillset for the position for which Dev was hiring. But because of this guy’s skills and his great attitude, the dev team really wanted this guy on board, so they created a position for him. Because this position was one that really had a foot in both IT and development, the company decided to place him in IT.

It took about two weeks for this guy, about whom the entire Dev team was really excited, to be co-opted into IT’s culture. He became self-important, lost his sense of collaboration, quality, or follow-through, and became a highly skilled yet marginally useful employee.

And this is the lesson to be learned from this experience: If the cause of a lack of quality output from a team is due to an institutionalized problem with the culture of the team or the company, trying to improve output by adding people to the team won’t work, because those people will be absorbed into the same culture of failure. It is the culture itself that must be changed to turn the team around.

And that can be one of the hardest things in the world to do because it requires the humility to realize that the problem is due to one’s own poor choices. And it requires the majority, or even all, of the team to accept that and resolve to change together.

And inertia is an awfully hard thing to overcome.

The stake in the ground

Today was the first day where I didn’t leave work frustrated with how difficult it is to learn the things I need to know to do my job. This was a very good thing.

What’s a bad thing is the principal reason why it’s been such a slog for me to date.

The platform I’m currently responsible for getting production-ready was originally built with very few specifications. The specifications were, mostly, “Make it do what the old site did.”

There were not one, but two major problems with this, both of which are fairly obvious.

The first was that the old platform’s processes weren’t documented either. Knowledge of how to use many of them were scattered throughout the company’s employees and management, of course, but with no BA, turning that knowledge into requirements is not an easy task. Other process knowledge left the company with old employees, and needs to be rediscovered.

The second problem is a little less obvious than the first, but still readily apparent: Just because the old site does something doesn’t mean the new site needs to do the same thing. Any new development should be with the goal of meeting business needs, not matching existing processes. Often, old processes are obsolete, or are workarounds for things that didn’t work exactly the right way on the old platform. If your old e-commerce site handles conversion of Canadian to American currency but you’ve since stopped selling to Canada, you don’t need that functionality any more. If your old administration console had a process that exported all orders to an XML file that a user transferred to the fulfillment service’s import function, it’s not necessary to build that export function in the new platform if it can instead export directly to the fulfillment service.

TL’s Fifth Rule of Development: When designing an upgrade to an application or service, the question to ask is not, “What does it do now?” The question to ask is, “What are the business needs to be met?”

So what was built was taking a powerful new platform, and wedging the old platform’s processes onto it, without really examining what the needs are nor understanding the new and possibly better ways the new platform can meet them.

Fortunately a few of the more onerous features haven’t been implemented yet, and I’ve been given the opportunity to put the brakes on what they’ve been doing and ask those questions: What do we need it to do? Can it be done differently? These questions have already yielded results that are going to allow me to meet the company’s needs far more cheaply, and far more simply, than otherwise would have.

And better still, the powers that be at the company let me do just that.

And that is my first major win at my new job.

Tapped out

The week ended with exhaustion and a feeling I was in over my head.

Not because I thought myself incapable, but because the demands placed upon me, Pope and BA/PM to get this project out the door were enormous and I’ve barely scratched the surface of the technology in which I need to become an expert.

The schedule was put together by people who are not developers, based, it seems, solely on the date they decided they need to go live rather than a sound estimate of what the minimum list of tasks is and the time it will reasonably take to complete them.

This is what we call “Schedule-driven development” and it never works. Why?

TL’s Fourth Rule of Development: Time, Cost, Quality. The business owner of the project gets to dictate two at most. Trying to dictate all three will set the stage for failure.

It’s an old rule which I’m sure anyone reading this has previously heard, but it bears repeating because business owners keep breaking the rule, in organization after organization, project after project. Sometimes the same business owner does this repeatedly, wondering why his projects keep crashing and burning.

But that’s the paradigm I find myself facing. There is a set of minimum marketable requirements, a schedule to get them done, and a specified number of resources to accomplish the task.

I knew there would be difficulty in changing the development culture of this company, but I didn’t know the immediate task would be so urgent and with such a broken structure. And I know I can’t begin the process of changing the company’s culture until this immediate task is complete. And my chances of changing the development culture hinge on how well I complete the task.

The good, however, is that both Pope and BA/PM are right there with me, they see exactly the same problems I do, and thus we have a united front in dealing with this challenge, and managing the business leadership when deadlines inevitably slip.

The fact that Pope is part of senior leadership is one reason why we’ve got a chance to make this plan work. Without him, I’d think we were tilting at windmills, at best.

The fire hose

As I get to know my new coworkers I’m starting to assign them nicknames in this blog. The papal conclave that elected a new Pope today inspired me, for a few reasons, to nickname my boss, previously referred to as CTO. He is henceforth “Pope”.

So Pope and I the last two days have been working on bringing me up to speed, and I have surely been “drinking from the fire hose.” I’m mentally exhausted.

Today became a different kind of trial, however, as a critical issue with the current production servers (directly impacting company revenue) consumed much of our time.

I found myself doing something I really never like to do but have many times found myself needed to do: dive into a complicated, poorly-documented set of running processes and try to figure out what the problem is. Pope and I tag-teamed it, with his understanding of processes and my understanding of code, with occasional calls to business users to figure things out. Eventually we figured out that this was a problem with our network, which had recently been reconfigured due to the opening of our new branch office (the one from which I’m working). Essentially, the internal firewall got misconfigured and blocked the processes from communicating with outside processes.

Which tells me the current version of our platform does something very badly: It doesn’t report when things aren’t working right. It “fails silently.”

TL’s Third Rule of Development: Never architect nor write your code under the assumption that everything will work as planned. Always develop with the exception cases in mind.

That rule goes double for any code that talks to something external to itself (a database, an API, a file import or export). Because those always seem to break at the most surprising times.

Fortunately most of this code is going to be retired when the new platform is release. Unfortunately, that’s no guarantee that the new code handles the exception cases appropriately, and a review is indicated.

Other fun things I discovered. A cron job runs every hour, on the hour. This cron job tries to execute two scripts that don’t exist. As far as I can tell, they haven’t existed for over a year because there are web server logs that show the same errors every hour going back that far.

This concerns me greatly because it, obviously, means there has been little to no quality assurance on the processes or the code to date. And I’m obviously worried that the new development has taken place under the same (lack of) constraints.

My solution is to lay the groundwork for a near-term plan to do a full review of the new code base. I know that CEO’s top priority is getting our new platform out the door as quickly as possible, as the E-commerce guy has all kinds of things he wants to do that are dependent on the new platform being live. So that’s first priority. But once that’s done, I want to do that full review and identify potential problem areas. I introduced CEO to the concept of ‘technical debt’ and told him what my post-release goals were in the context of ‘paying down’ the technical debt.

Mostly, I don’t want to be trying, yet again, to figure out how to build stable code on a brittle foundation.

The other item of note today was that CEO was eager to plan to build my team. I told him I had several people in mind, but that I needed a couple weeks to really get to understand the company’s needs before I made any recommendations. Pope was quick to back me up on that, saying he wanted my focus right now to be getting acquainted with the new applications.

But this is a good thing for my desire to build myself and my company a great development team.