Paddling the Outrigger

CODE does many things, but what keeps our boat afloat? Simply put—writing software! Everything we do pretty much revolves around that, and the task of writing custom software and providing consulting services for our customers is our core business.

Not only is this a core part of our business, but it is also the most difficult thing we do. Each project is super-important to us, because software projects tend to be large, and messing up even a single project has dire consequences.

The Development Process

We have quite a history in development processes. Markus has a lot of background in processes such as Waterfall, the Unified Process, and Agile. In fact, the first time Microsoft hired Markus they put him in charge of Rational Rose integration into Visual Studio. Rational Software is the inventor of UML and the Unified Process and was later purchased by Microsoft. So with all this background in various processes, which one do we use for our projects?

There is no simple “one size fits all” answer. Instead, we adjust our process to customer needs as well as the technical characteristics of each project. However, it is fair to say that we always aim for a very simple and lean process based on Agile. We find “Less is more” is good guidance.

There always is a question about which tools we use for requirements analysis, work item tracking, and more. Some of that is standardized through technologies and platforms such as TFS, although the approach needs to be adjusted to the needs of each customer. For others, we like to give teams the freedom to use the tools that work best for them.

However, whenever we add new tools to the mix, we need to discuss it and make the decision together. It is important that such assets are always accessible and can be maintained and accessed over time. We do not want to switch to some new tool on a whim just “for the heck of it” and then perhaps face challenges in accessing that content a year or two later.

Asset Management

Source and asset control seems to be a hot topic; in many ways to a surprising extent. The way we look at it is similar to our development process—keep things simple. Over time, we have tried a number of different approaches, ranging from Visual SourceSafe to TFS, and more recently, things such as GitHub and Mercurial. At the end of the day, we seem to always come around to using Team Foundation Server (renamed Azure DevOps for work in the cloud) in some incarnation, these days always using the Git protocol for source control. That should be your default assumption, although in special cases (such as for CODE Framework), we also use things such as GitHub.

Note that CODE has a history of long-term maintenance and reuse of code. Probably far more so than other companies. There is a lot of value in having our assets in a shared store that goes back decades and includes all projects we have been working on. For us, this single shared store, is Team Foundation Server / Azure DevOps.

Our Pow Wows

Like any other software company, we tend to have meetings. Maybe not as many as others, but still quite a few. We meet amongst each other, have team scrums, and meet with customers. We are constantly evolving our meeting strategies in an effort to keep meeting times to a minimum, yet still allow a geographically disjointed team to act as a whole.

Our current meeting strategy is a combination of Skype, GoToMeeting, Slack, and a few others. This may have evolved by the time you read this, so ask around. One staple of our meetings is that we record almost all of them. We use built-in recording features (such as GoToMeeting’s recording feature), or an external tool (such as Camtasia) to record meetings. Most likely, as the newcomer, you won’t have to worry about recording it, since it is usually the meeting organizer who does the recording. However, once you get to a point where you call your own meetings, make sure you do not forget to record them. The recording gets uploaded to Screencast.com, filed away neatly into the appropriate folder, and with an assigned description so we can search our database of recordings. (Not having a good description makes it almost impossible to search and thus it makes the recordings almost useless).

Remember Pele, the goddess of late timesheets? Well, we also have a god of forgotten recordings. His name is Kūkaʻilimoku, or Ku in short. He is even scarier. Look him up under “human sacrifices.” 😈

Presenting Progress to the Customer

For those who are working on customer-facing projects, please make sure you consult with your manager about how exactly to communicate with the customer for that project. There is one aspect that remains the same for almost every project—we provide progress updates to customers in the form of short videos. Typically, these videos are a few minutes long and show off all the new things that have been recently completed.

There is a very important reason for these videos. They document the progress of the project, and they document why certain things were done. We have learned the hard way that having this kind of backup information is very, very valuable for a variety of reasons. For instance, it can be valuable when we need to go back to see what we decided in a certain meeting or iteration. It can be valuable when we need to see what was accomplished. It can be super valuable even for you specifically, in case someone gives you a hard time about what you programmed and why.

This is something we do always and for every project. There is no excuse for not doing it. Remember Ku, the God of War? Boy does he love his progress update videos. 😉

Doing What’s Right for the Customer

We have a simple philosophy in terms of our relationship with our customers—whenever possible, we strive to put what is right for the customer first. We simply ask ourselves “what would be the best possible scenario from the customer’s point-of-view that would make the customer love us and our services and/or products?” We then try to implement that as much as possible.

Here is an example: Our magazine subscribers often have the need to change their delivery address so they can still get their magazines after they move to a new home. In the past, they had to call or email us to change their address. This had to do with the fact that if a customer were to move to a different country, the mailing expenses changed, and figuring out what the new pricing should be, was a complex process on our end. Therefore, we did not let them change the address on our website. But then we changed our perspective and we said, “it would clearly be the best for the customer to change their own address.” We now support this on our website. We still have the pricing issue, but that is something we deal with, rather than inconvenience the customer. We now manually handle this, and as it turns out, scenarios where complex price re-calculations apply are rare. So much so, that we can pretty much ignore them. Spending even an hour or two on this would be more expensive than the potential increase in mailing expenses for all customers combined.

However, note that there are common sense limits to this. One could argue that clearly, it would be the best for the customers to get their subscriptions free. But from a business point of view this simply isn’t feasible, and nobody in their right mind would argue for that.

The same applies for the software business. Scenarios are more complex, so we have to talk about them on a case-by-case basis. But ultimately, we want to apply the same principle. Let’s do what’s right for the customer, if at all possible!

Tools of the Trade

An interesting aspect of software development is the question of what tools, technologies, and platforms to use. Historically we are a Microsoft shop, but that does not mean we are limited to Microsoft tools. In today’s world, we use a range of tools and platforms, including Windows and Linux, different cloud platforms, different development tools (such as the Visual Studio family of products, as well as others), programming languages (C#, JavaScript, Java, Swift, and many more), and so on.

As you can see, we are open to a lot. Where things get tricky is when we add new tools and new frameworks. Especially in web development, there is always a “framework of the week” and a new library or tool. We are open about adding new ones, but it needs to be a well thought out decision. If you have something new you would like to add, let’s talk about it! We need to make sure it fits into the overall strategy. We need to make sure we understand the long-term implications. We need to make sure we understand what it means for the customer and whether the customer even allows it. We need to understand the dependencies. We need to make sure we can still guarantee the quality of the overall product as well as the newly added component, since we are legally responsible for both.

There is a lot that goes into decisions like this. We also can’t always chase the latest and greatest thing in production projects we work on for clients. Imagine if every single person on every project was to simply go off and add new things in an uncoordinated way! Software development is already crazy enough without this! 😄

Nevertheless, adding new technologies is an important aspect of what we do. Let’s do it in an orderly fashion and include other people in the process. Perhaps the next DEP can even be about that cool new thing you found!

Not Invented Here… or is it?

In the software industry, we often hear people complain about the “not-invented-here syndrome.” What they mean is that developers too often want to re-invent the wheel rather than using technology that is already available. We share this sentiment to some degree. Why re-invent when what we need is already there? However, we know there are limits to this. After all, we are not just implementers, sitting in a large corporate IT department.

We see our organization as engineers and inventors who think up and provide new solutions to improve the overall development landscape. Historically speaking, we have been very successful with that. While we certainly do not want to re-invent the wheel, we do want to question whether an existing wheel is what we really need. And if we discover that we need wings instead, we need to evaluate what kinds of wings they need to be. You do not just bolt 747 wings on to your contraption because “they surely must be good enough.” We want wings that provide the best-case scenario for our specific needs, and that often means developing new wings. We expect our developers to have the skills to do so. Well, the software equivalent anyway. 😄

What we really need is a good way to balance the use of existing technology and the invention of new components. We need to carefully evaluate whether something that is already available will allow us to operate at the level of quality we require. We need to make sure we fully understand the implications of bringing in an existing component or technology. Too often, we see developers using something that “kind-of matches,” without a comprehensive understanding of the implications and dependencies. We do not consider that acceptable.

How We Bill Our Customers

Most of you do not have to worry about how exactly we bill our customers, but we would still like to provide some background information about the process.

In almost all cases, we bill our customers based on the actual hours we work. In other words: we sell our services, rather than some kind of finished product. This also means that we do not do fixed-price projects. Or, at least, the cases where we do are few and far between.

In terms of the actual amount we bill for each person, it depends on what technical “level” we consider the person to be. We have four different skill levels, from 1 (lowest… typically testers or junior developers), up to 4 (renowned experts, authors, and speakers at major events). Most developers fall into levels 2 (a professional with considerable expertise) and 3 (a senior developer with leadership skills, who is usually also a published author and speaker).

A Word about Contracting

Some of you reading this will be full-time employees. If so, you can skip to the next section. For those of you who are contracting with EPS, please make sure you understand what contracting means. We have additional documentation for those who are new to such a setup, so please refer to that for more information. However, the short version is that you are a vendor. You provide services or goods that EPS buys from you. You are not an employee. You need to have your all own tools including computers and software licenses, you need to pay your own taxes, you set your own hours, and so forth.

We have a policy of inviting many of our contractors to various EPS initiatives. We have training, events and other initiatives that are open to anyone, ranging from EPS employees to contractors, and even simply members of the development community that have no other business relationship with EPS. While we are happy to extend those benefits indiscriminately, there is no guarantee we will continue to provide them or that we will provide them in the same fashion and to the same group of people.

What We are Not Good At

We try our best, but clearly, we are not good at everything. As is often the case, our biggest weakness is also one of our strengths—we are a geographically disjointed group of people with different backgrounds, different experiences, and different technical expertise. We are also not good at micro-managing people. Many would not consider that a negative. 😄

However, we do have to acknowledge that we are not good at “managing people into the best they can be.” We simply rely quite a bit on people being able to organize themselves within the boundary conditions we define. We also often rely on team members bringing issues to our attention because due to the virtual nature of our teams, issues that are obvious to some, are often completely unknown to management.

We acknowledge these weaknesses and are steadily working to improve them, but we rely on each individual to help us work towards improvement.

Another problematic area is that we are simply always super busy. We are not a large enterprise that can set aside a lot of resources for overhead tasks. One can argue that such is the reality of life, even for many large organizations. Yet it certainly is an area we are aware of and try to improve, although it remains an elusive goal.