When you change code, how do you know that you’re not breaking something? If the code change is small, it can be pretty easy (especially if you have tests). I’m talking about more complicated code changes.

Sure, you have unit tests, but how do you know that everything in the system works together correctly?

Sure, you have end to end acceptance tests for all of the scenarios that you know about, but what if a scenario exists that you didn’t think of?

We can come up with any number of excuses for why bugs happen in production. But what happens when a bug could cause a big problem?

I’m in this situation right now because the relatively large code change I’m implementing could impact how much money we charge our customers. The code I’m writing takes in some input files from a third party and processes them. We could have a big problem if someone gets overcharged or undercharged, or even worse, not at all. There are lots of things that can go wrong. I have a lot of good acceptance tests for my code, so I have good test coverage for the scenarios that I know. What I worry about is the scenarios that I don’t know, or what could cause my code to not get called at all. Because of this, I have to think past the traditional ways that I usually test things.

Searching for test cases

I did a lot of analysis on the data that my code is going to consume. I even wrote some small apps and SQL queries that will parse historical data and look for different combinations of data, and used that to come up with the test cases. What’s tricky is that some of the scenarios do not happen very often, so that means I need to do more digging to find them. At some point, this can become tedious, but in my case it’s worth it.

Watching for unexpected scenarios

Thanks to my data analysis, I have a list of expected scenarios that I’ve seen from past data. In addition to writing tests for all of these scenarios, I’m also writing some queries that will check for evidence that some unexpected scenario happened in production, and I’m running these queries every day. By doing this, I’ll be aware of any potential changes in how the source data comes in, and I also avoid having to write acceptance tests for scenarios that probably aren’t going to happen.

Throw exceptions when you find unexpected scenarios

Not only do I have queries to check for unexpected scenarios, I also have inline checks that will cause the process to stop and throw an exception if I encounter specific unexpected scenarios that could cause an issue, especially when the issue would not otherwise be obvious (in other words, it wouldn’t cause the system to fail, but the system might give me incorrect results). In many cases, it’s a waste of time to discuss, implement, and test some edge cases that is very unlikely to ever happen, but I at least want someone to know if by chance that happens. Now if you’re writing a UI for a website, you might not have the luxury of being able to do this, but when you’re just processing backend files, you can get away with things like this.

Parallel testing against production data

We have a test environment set up with 2 databases – one has 2 day old production data and one has 1 day old production data. We restore these databases from backups every morning and then run in all of the files from 2 days ago into the 2 day old environment, then we compare the results with what’s in the 1 day old database, and theoretically everything should match. There are always exceptions, especially when you have data that was modified by a user after it was created in the database, but this allows me to easily check almost every column on a database table and see that the results from my process match what is currently in production. This has been a huge lifesaver, not only in finding bugs in my process, but for finding unknown scenarios, and for finding bugs in other related processes as well. People have a lot more confidence in your work when you’re able to show tangible proof that your system is working the same as what’s in production.

Writing audit queries that validate the process end to end

In addition to the queries that check for unexpected data, I also have queries that validate that any data received at the beginning of the process will have some resulting output. I need to make sure that the process isn’t silently failing or is failing in a way that I don’t expect.

Checking logs

Hopefully your app logs exceptions somewhere, so as a last resort you should always check for any fallout in the logs.

A different thought process

I find this way of thinking to be a different thought process when it comes to testing. I’m moving past the mechanics of testing (what are my test cases, what tests am I going to write, how can I mock this class, etc.), and trying to find whatever means necessary to not break stuff. Sometimes this is done with automated tests, manual tests, inline sanity checks, writing exploratory code to help me discover scenarios, or some form of production monitoring. The latter three are where I’ve found I’m doing things in a way that I haven’t always done before.

I think the shift in mindset partly comes from owning the responsibility for a feature. At one point a long time ago, I wanted to get my code to work and let QA test it and find bugs. Then I moved to wanting my code to work and wanting to come up with a way to test it. The next step in the progression for me is finding ways to be able to make large changes to the code, not break stuff, and ensure that everything will work with no impact to the business. In each step in the progression, I’m starting to look at the problem at a larger scale and looking at business value and business impact instead of just technical concerns.

One thing I love about software development is that it requires a balance between logical thought and creative thinking. Both are required to be successful, but this is really easy to forget, and it’s the creative side that often gets ignored. I would argue that ignoring the creative side is probably the worst thing that you can do.

When I say that, I’m talking to myself first. As you know, there is often a disconnect between what you believe to be true in your head and how you actually live. I feel like my busy, efficiency-driven life is forcing me in one direction. At work, I’m trying to become more efficient, reduce cycle time, meet deadlines, complete tasks. At home, I’m trying to balance having a family, trying to keep the house from becoming a disaster area, and trying to get enough sleep. Even now as I’m writing this, I know that I could be working and I almost have to tell myself not to. All this leaves little time and energy to be creative. (Proof of this is my drastic decrease in frequency of blog posts over the last year.)

Here’s the problem – it doesn’t really matter if you’re efficient at something if you’re being efficient at the wrong thing. Also, in this fast changing world of technology, what was the right thing yesterday might not be the right thing today. What gets lost when you’re too task-focused is innovation.

We’ve all heard of Google’s famous “20% time” where employees can work on whatever they want. You hear of other startups copying the same idea. This isn’t just another employee perk like free lunches and workout facilities. This is a calculated decision to give people time to innovate, because the company feels that the value of the innovations will far exceed the time spent. Many more established companies are starting to launch “innovation incubators” where they take smart people and let them go off an build innovative stuff without the drag imposed by bureaucracy, meetings, and big-company red tape.

For the rest of us who don’t work at startups or internet companies, innovation may not carry as much value. If you’re maintaining back office internal systems, your tasks are often straight forward and you’re probably not going to come up with a revolutionary idea that will bring in thousands of new customers. But that doesn’t mean that there’s no value in innovation. There are still opportunities to innovate in these work environments, because all software development is a creative endeavor. You still are creating something that will need to meet the needs of the users, and we want to come up with creative ways to do it better, faster, and cheaper.

Developers are strange creatures sometimes. Our quirkiness is often what makes us successful. We may seem to be very structured, logical people who just want to put on their headphones so that we can complete the ticket that we’re working on and move on to the next one. This is true, but developers are also impatient and lazy. We don’t like waiting for our code to compile, we don’t like using frameworks that make things hard to do, and we don’t like writing the same code over and over, and this can drive people to try and come up with creative solutions — if they have room in their head to do it.

I find that if I get overly task-focused, the innovation switch in my head turns off. There is a big difference between “today I’m going to work on X, Y, and Z” and “today I’m going to solve a problem”. One approach has the solution outlined for me, and the other one forces me to innovate. In both cases, a problem is going to get solved, and the solution might be the same either way. The point is that when I go to work with the innovation switch turned on in my head, there exists the potential for something great to happen. It might be completely unrelated to the task at hand, but the value of that innovation could far exceed the value of the everyday task I was working on.

For most companies, it’s not going to make sense to give your employees 20% of their time to work on whatever they want. But there are still things that you can do to encourage innovation.

Pose problems, not solutions

Chances are someone higher up than you in your company is deciding what you’re going to work on. This is good, but I’ve noticed a difference in the way in which these tasks can be handed down. Sometimes I’m given a series of tasks that solves a problem. Other times I’m given a problem and am asked to solve it. I greatly favor have the second approach, for several reasons. First, if I’m given a problem without a solution, I take it as a challenge to come up with a creative way to solve a problem. Second, I’m motivated to solve the problem because I can understand the problem and can see the value that is going to come out of the solution. Third, I just might come up with a more innovative way to solve the problem.

Encourage experimentation

One idea that we introduced at work was the idea of “experimentation time”, where someone can propose something that they want to try out, ask for amount of time to try it, and then go do it and report back the results. This could be anything from trying out a new web framework to refactoring part of our codebase to trying to find ways to run tests in parallel – pretty much anything goes, as long as the goal is to find a way to improve something that we’re working on.

While our IT leadership loved the idea, no one has taken advantage of it yet! I find that interesting because people complain that they don’t have time to innovate but then they don’t actually take the initiative to do it. I’m not working in one of these IT departments with ruthless taskmaster bosses that force unrealistic deadlines on people. I suppose this can be expected from people who typically are focused on getting things done and who are often rewarded and complimented for doing so.

Maybe we should start requiring people to take time to work on something innovative, kind of like how you might be assigned a project in school. Sometimes people don’t feel like they have the freedom to work on something that isn’t working towards meeting a deadline. We practically have to force some people to attend conferences (any other time, people would jump at a chance to take a free trip to a nice destination to learn something and have fun with their co-workers). If we truly value innovation, then we need to find a way to get that message out.

Start with yourself

Time to preach to myself again. How can I sit here and write all this when I’m not giving myself time to innovate and learn? I read this quote today:

Nothing creative will come out of your efforts if you don’t allow your best ideas to incubate. Follow the lead of Warren Buffett and allow time for quiet reading and thinking every day. I recommend devoting at least one hour a day to learning, as Ben Franklin did. Can’t find the time? While you’re commuting or en route to meetings, stay off the phone and listen to a podcast or comtemplate what you’re been reading. You’ll be surprised by what comes out of your brain if you give it a rest sometimes.
–Verne Harnish (Fortune magazine)

The most important things that have happened in my career this year were not because of things I accomplished, but because things I’ve read and heard at conferences, and things I thought about when I was in those spaces when my mind felt clear enough to think about the big picture. Some of these ideas have been career changing for me. Not only that, it reinforces what I’m doing on a day to day basis and gives me motivation to handle the task-based work that consumes most of my day. The challenge is finding the right balance.

People are motivated in many different ways. You can probably think of situations at work where you’ve been really motivated to do awesome things. But what really motivates you if you look beyond the surface?

I’m going to use my current situation as an example. I’m currently doing maintenance on a 6 year old system with a Silverlight front end (and no one uses Silverlight anymore). From a purely technical perspective, it’s not hot new technology, and over the last couple years I’ve watched several developers get sick of doing it. I question whether they are seeing this big picture.

Here’s the thing — the maintenance that we’re doing on our 6 year old Silverlight app is providing a ridiculous amount of business value. I’m able to make changes that have an immediate impact on the users’ ability to do their job, sell new products, and reduce costs.

Are there more “fun” technologies out there? Sure! I play around with things like Ruby on Rails and React on the side because I’m not using them at work and I enjoy working with technologies like that. But my attitude at work depends on my true motivation.

A progression of thought

I’ve spent a lot of time thinking about what motivates me in my career. Am I going to get bored with software development at some point? Are there other roles that I might want to pursue? There are lots of good questions to ask.

I came to the conclusion that I’m not going to get bored with software development because it’s such a big part of our world and the things you can do with technology are too exciting. I’ve also started to understand the underlying reasons that give me motivation.

When I started out in my career, I was like a kid playing with toys. I wanted to do cool things with new technology. I had a limited understanding of what was important to the business, and I was basically just doing whatever work items were in front of me (hopefully with new technology). I had a very small and self-centered view of the world.

Later on, I realized the importance of providing business value. I got into lead roles where I had more interaction with people in the business, and I started to see what was important to them and how technology could solve their problems. I still enjoyed working with new technology, but I started placing more importance on solving business problems. But even at this point, I was missing something very important.

The real underlying motivation for me now is improving people’s lives through software. I want to improve the lives of my users by developing software that makes their job easier and makes them more successful. I want to improve the lives of my managers by helping to solve their biggest problems. I want to provide value to the business and help them achieve their mission. And I want to improve the lives of the people on my team and help us all get that good feeling that you get when you work together with people that you like to achieve something incredible.

It doesn’t really matter what technology I’m using. What really drives me are people. Without people, I’m just typing words on a screen. But when you add people into the mix, I have a much larger purpose then just developing an application. I’m using technology to change people’s lives. And that is a good reason to get up in the morning.

When I think about a lot of the efforts that we make to improve the software development process, I feel like we’re usually trying to make improvements within the system that we are currently living in. What if we could instead disrupt the world that we’re living in by changing something that dramatically changes the game?

Think of what Uber has done. I feel like everyone uses Uber. How many people do you know used taxis on a regular basis? Maybe you used a taxi when you absolutely had to, like when you’re getting from an airport to a hotel. But on a daily basis? No way. The other day a co-worker took an Uber to get to work after dropping his car off to get an oil change. When I asked him how he was going to get back to pick up his car, he said, “I’ll figure it out this afternoon.” That is a game changing idea. It makes you think about transportation in a way that you never thought of before.

Let’s think about the world of software development. I tried to think of some of the big changes I’ve seen in the last few years.

• DevOps and cloud computing – it used to take weeks to get a new server purchased and stood up, but now we can go to a site that automatically provisions a server, installs what I need, and then I can get rid of the server as soon as I’m done with it at a fraction of the cost.
• Git – I remember the first time I heard about branching per feature. In the world of centralized version control systems, branching and merging is hard enough that you would never think about branching per feature. Git makes the cost of branching and merging almost zero, which enables you to work in a completely different way.
• Dynamic languages – I can change a line of code and see the results immediately without having to compile
• Remote working – collaboration tools are improving to make it much easier to work with people that aren’t in the same location as you

Think about the application that you work on and business in which you operate. What are some things that are annoying and slow you down? Some of these things are obvious, but many are really hard to see because they’ve just become “normal” to you. You’ve accepted those things as facts. But what if there were a way to change the facts?

Let me give you some examples.

• What would happen if I didn’t have to wait so long to get answers from people in the business?
• What would happen if I had a faster development laptop?
• What would happen if we were using a different framework/platform/language?
• What would happen if our team could all sit together in the same space?

Those are good questions to ask, and those things might provide a lot of value, but that’s still operating within your current plane of thought. What if we ask more mind-blowing questions?

• What will happen when we improve smartphone battery life so that a phone can operate on a full charge for weeks/months?
• What will happen when computing and network speed increases so that web pages load instantaneously?
• What could you do if everyone had virtually unlimited data and download speeds were measured in gigabytes per second?
• What will happen when mainstream video chat is no longer a grainy, choppy FaceTime or Hangouts video and instead is a clear 4k data stream?
• What will you be able to build if all of these were true?

Will those things help you out today? No, because they mostly aren’t a reality yet. That’s not the point. By thinking about game-changing ideas, it forces you to think on another level. It forces you to think outside the box. It’s surprisingly hard to think outside the limitations of the world in which we live everyday (remember The Matrix?).

This is why I attend certain software development conferences and not others. For example, I’m writing this at the Path to Agility conference. I love going to open space conferences for the same reason.

I go to conferences like #path16 not just to hear mind-blowing ideas, but to hear things to make me think about mind-blowing ideas.

— Jon Kruger (@JonKruger) May 26, 2016

The technology world is changing at an extremely rapid pace, so we’re going to need to change the level of our thinking.

I have 1,408 emails to answer now–prioritizing is important. The younger generation is constantly looking at their phones, so they don’t have time to think strategically.

— Cheryl Krueger, founder of Cheryl & Co.

In a world where we seem to value busy-ness, I feel like we frequently got lost because we don’t often take time to think about where we’re going. I’ve fallen into this trap many times.

Every time this happens to me, I eventually work my way out of the insanity and then wonder what happened that got me so busy in the first place. The thing is I’m almost always bringing it on myself. It’s not like someone’s working me into the ground or anything, I’m just not taking time for downtime.

Not only is over-working yourself tiring, it’s a huge mistake. I find that when I’m constantly consumed by doing things and getting things done, I have no time to think strategically. Some of my best ideas come to me because I my mind is clear and I give myself time and space to think.

Reading

My wife loves to give me a hard time for not reading books. I’m not much a fiction reader, I can’t remember the last time I read a fiction book (it’s probably been since college!). Most of my reading these days is related to technology and business, which some would say is not light reading.

I find it inspirational. I love reading about what people are learning and how people are using technology to change how we do things. We live in an amazing time when anyone with a good idea can turn it into something that changes the world. I’m probably not going to be that guy, but I like being reminded that anything’s possible.

Conferences

I’ve been burned out on conferences for the last couple years. I’ve stopped attending several conferences and user groups that I used to attend on a regular basis. I’m not someone who typically likes to sit in one place and listen to someone talk for an hour, especially when it’s a topic where I could spend 20 minutes reading on the internet and get all of the same information.

I still go to some conferences, but I don’t go planning to learn anything specific. I go because it gives me a space to process ideas and think clearly. I go to talks just to give my mind a trigger for my thoughts. I love talking to people at conferences to hear the ideas that are floating around in their heads.

Free thinking at work

This is a tough one. When I’m at work, I’m putting a lot of effort into focusing on a specific task. I’ll put headphones on so that I can focus on writing a certain piece of code. When we’re in meetings, we try to have a very focused agenda. Everything is focused on completing tasks. So what can you do to promote free thinking at work?

We’ve started doing book clubs at work to promote learning. Some of these are technology focused, some are focused on business acumen. A lot of good conversations happen at the bar after work when people are more inclined to open up about what’s going on in their lives. It’s not that we come up with amazing ideas during these times, but it clears a little space in our head for thoughts to come in.

This is important

I’m starting to make a conscious effort to find ways to stimulate thinking. When I find myself with extra free time, I’m not trying to find projects to fill that time. I’m reading less about “how to use technology X” and I’m starting to read things that will expand my horizons.

What works best for you? That’s up to you to find out, but make sure you’re giving your mind some space to find it.

I find that as software developers, we sometimes lose sight of what it is like to be a user of the systems that we develop. This is ironic since software developers probably consume more software than the average user.

For the apps and systems that I use, I have two very high level yet very important requirements for updates to the application:

• 1. Works as designed (i.e. not buggy, doesn’t crash, etc.)
• 2. Is at least as fast and easy to use as the last version (hopefully faster, but definitely not slower)

Taking the pain

It’s been a rough week for me, mostly due to the fact that we decided to upgrade our solution from Visual Studio 2012/ReSharper 7 to Visual Studio 2015/ReSharper 10. At first, I got excited when I typed “?.” for the first time, but the excitement quickly faded.

• Everything in the IDE felt slower
• Visual Studio would often chew up 60%+ CPU on all cores, even when it seemed like nothing was happening
• ReSharper wouldn’t show me the results of my tests until ALL THE TESTS were done running
• The ReSharper test runner would die a slow death and crash if I ran a lot of tests
• If I open a solution that has a Git repository, I can’t connect to TFS to open work items in the same solution

All of this made me long for the good old days of VS2012 and a version of ReSharper that worked (not to mention that we gave these companies money for these new versions!).

Don’t get me wrong, these newer versions have a lot more features than the old versions. The problem is, I don’t use 90% of them, and they failed to meet my two most important requirements that I mentioned.

I can see how this happens.

Executive: “We need features X and Y so that we can release a new version and sell software!”
Dev team: “But we don’t have enough time to do that well.”
Executive: “That’s OK, just ship it anyway, they’ll purchase it and then we’ll fix the issues.”

In my case, they’re going to get away with it because I don’t have an alternative to Visual Studio and ReSharper right now. But it still feels wrong.

Running through mud

Another example: Why does every new version of an operating system have to get slower? I have a 5 year old MacBook Pro that I had to upgrade from Snow Leopard (which was working great, BTW) to El Capitan because no one was supporting Snow Leopard anymore. Now my MBP feels 5 years old and it’s much slower.

If you’re a Linux person, you’re probably laughing at everything that I’m saying because everything for you is lightning fast with the command line, simple user interfaces, etc. When I was last doing Ruby, we used gVim as our IDE (basically a simple text editor with basic highlighting, basic autocomplete, tabbed windows, and of course the power of Vim). Contrast that with the bloat of Visual Studio.

The opposite experience

This morning, I got the Android Marshmallow update for my LG G4. When I read up on Android Marshmallow, the general sentiment out there seemed to be, “There’s nothing big in this release, just some minor features, increased performance, and better battery life.”

What!!!! I’ve only had Marshmallow for about 4 hours, but I can tell that it’s a little snappier than before. They made minor usability changes in the OS that are nice. I can’t speak for the battery life after just 4 hours, but it doesn’t seem to be any worse than before from what I can tell.

What a breath of fresh air. I don’t have to sacrifice performance for unnecessary feature bloat. I don’t have to buy a new phone to make the latest OS work as designed (right, older iPhone users?). All this makes me a happy user.

You do this to people too

What do your users have to say about the updates you release? Sure, you’re going to have the curmudgeons that don’t like any change, and you can’t please everyone. But too often we ignore the non-functional requirements like performance, usability, and user happiness. Those things might just be more important to your users than those new shiny features you’re working on.

Every business cares about making money and reducing costs. Yet every day I press a button and sit idly while I watch a little progress bar move. This happens every time I want to run an application or run a test.

Compiling code is something we’ve just gotten used to. Maybe that’s not the right phrase — we’ve learned how to put up with it. Granted, things are a lot better than they used to be. My first job after college was working on a C++ application where changing some of the foundational header files meant 30 minutes of compiling just to rebuild the application!

When .NET came out, they said that it compiled so fast that you would wonder if it actually did anything. That was true on demo apps that only had a few source files, but as your application grows and grows over time, those compilation times are quite noticeable. Certainly it was better than it was in C++, but that only makes you feel good for so long.

Let’s compare this to working with a dynamic language like JavaScript. When I’m coding JavaScript, it runs my tests in less than a second whenever I save a file!! No compiling, no loss of momentum, and oddly enough, dynamic languages don’t run noticeably slower than compiled languages for the kinds of applications that most of us are building.

Scary math

How much is compiling costing you? I decided to find out. The application that I’m in is 5 years old and has a fairly sizable codebase. Rebuilding the entire solution takes about 2 minutes, but usually I don’t need to rebuild everything. If I change a test file and run the tests, it still takes 30 seconds to compile what it needs to run the test. My machine is a year or two old, but it’s a pretty solid development machine with plenty of RAM and everything running on SSD. Your codebase may be smaller (or larger) than mine, so the compile times will vary. If you codebase is smaller because you app is younger, think about what it might be when your app is 5 years old.

There is a Visual Studio extension called Build Monitor that will record the compilation time every time you compile and then dump it to a json file. We all installed this and we recorded compile times from several different developers over a couple weeks, and here’s how it came out:

99 hours of dev time
5.4 hours spent compiling

… which means that 5.45% of our time was spent waiting for the code to compile.

Let’s put this in perspective:

If I code for 8 hours, I lose 26 minutes to compiling each day.

If I code 6 hours a day on a 6 month project, I lose a whole week to compiling.

Spread that across your entire team and multiply that by the average hourly rate of your employees.

5 days lost x 6 hours of coding time per day x 5 devs x $60/hr = $9,000

That’s real money!

Note that we haven’t taken into account that I can’t take advantage of my tests as much when the cost to run them is higher, so I’ll write a bunch of code before I run the tests, which makes diagnosing problems harder.

We also aren’t taking into account the slowdown that comes from having to stop for 30 seconds and go find something else to do like check email while I wait.

We also aren’t taking into account the lost business value because we can’t deliver features faster.

We also aren’t taking into account that someone out there is writing code that is trying to take away your market share, and if they can do it faster than you, they have an advantage.

What can we do about this?

Here are some things you can try to reduce compile times.

Get an SSD

There’s absolutely no reason why you should not be using a solid state drive at this point. When I switched to an SSD, my code compiled 3 times faster. You can get a 128GB SSD on Amazon for under $50. If your company won’t buy one for you, buy it yourself.

Get a faster machine

A new machine isn’t as cheap as an SSD, but if you can get a faster machine and speed up compilation time, the machine is going to pay for itself very quickly. At least make sure that your current machine isn’t strapped for RAM (which is really cheap).

Check your build settings

Once you download your nuget packages, you don’t need to check for them on every build! I like to leave this box unchecked.

Make sure the number of parallel project builds matches the number of threads your machine can run at one time. Also, when you run your code, you should only be building the projects that you need to run the code.

Split up your solution

If your solution contains a bunch of projects that you don’t ever edit, they’re just taking up memory and compile time. I like having one solution that has everything, but it can’t hurt to make smaller solutions that only have subsets of the code that you need in certain circumstances.

Unload projects

If you don’t split up your big solution, you can unload projects by right-clicking on the project in the Solution Explorer and selecting Unload Project. This will essentially remove the project from the solution that you have open without actually removing it (unloading is a user-level thing, so you can unload what you want without affecting your other team members).

Consolidate projects

I see lots of solutions where there’s a project for the data layer, a project for the business layer, a web project, and many more. The problem with this approach is that every time you compile, it has to copy .DLLs around to all of those different bin\debug folders, which takes time.

I would recommend consolidating projects whenever you can. Yeah, this might allow someone to reference the data layer from a controller instead of going through the business layer, but we all should know what you should or shouldn’t do in a codebase without having to have project boundaries enforcing it.

There is one caveat here… if you consolidate projects, then you can’t unload them anymore and you’ll have to compile them all the time. So while you might save time by consolidating projects, in some cases you could increase people’s compile time because you force them to compile code that they might otherwise unload.

Rethink your language choice

If you’re using a dynamic language like Ruby or Python or JavaScript and you’re still reading this, you may be mocking .NET developers right now. People that use dynamic languages can run their tests anytime they save a file. They can deploy changes to code by just deploying a single code file instead of compiling all of the code and deploying it. They can change a line of code, hit F5 in the browser, and immediately see what will happen. They don’t have to spend $500 for their IDE. They don’t absolutely need to have super high end machines to do development. And oh by the way, they aren’t spending 5% of their day watching their code compile.

(Yes, I know there’s a free version of Visual Studio, but how many of you are using that at work?)

I did Ruby on Rails for a year, and not only was it nice to not have to compile, I just loved the language. You really can do a lot more with less code. I felt like someone took off the training wheels and I could just write code that did what I wanted to do without all of the ceremony.

I realize that it doesn’t make sense for most teams to rewrite an existing codebase in another language just to avoid compilation. However, I will say this – someone else is competing against your company, and by using another language, they could have a 5% (or more) advantage. Ruby on Rails is very widely used by startups, and no one is more pressed for time and money than a startup.

C’mon .NET

I’m sure there are reasons that .NET can’t become an interpreted language like Ruby, but why can’t it? You can already make dynamic method calls in .NET using reflection, and at runtime it will attempt to call the method that you specified and will throw an exception if it can’t find the method. So why can’t everything work that way? Compilation may still have value as a sort of test to make sure that everything does link up, and it probably makes runtime faster if I can compile my code before I deploy it. But the real win will come when I can write .NET code and run it without having to check every method call and check every line for syntax errors when I’m only going to execute a few lines of code in a test.

Yeah, I know, now there’s ASP.NET Dynamic Compilation, but when I read about it, it just sounds like moving the slow compilation to the web server, which is convenient but isn’t going to save a lot of time when developing from what I can tell. But I haven’t actually tried it, so I suppose I could be wrong (I hope I am).

What else am I missing?

Do you have any ideas, tips, or tricks for how you’ve reduced compilation time on your team? I’d love to hear your thoughts! We’re all tired of watching progress bars.

The Task Parallel Library is nothing new (it came out with .NET 4), but recently I had to diagnose some slowness in my application and I thought that the TPL might be what I was looking for, so I dove in.

Doing work in multiple threads is nothing new. You’ve been able to do new Thread(...).Start() and ThreadPool.QueueUserWorkItem(...) for some time now. But if you’ve used either of those methods, you know that it’s not simple and it usually feels like more work than it’s worth.

This is where the Task Parallel Library is awesome — it makes multi-threading easy. This doesn’t mean that it’s trivial (you can still have deadlocks, race conditions, etc.), but now you can introduce multithreading into your application with minimal effort.

I’m guessing that many of you have had the same problem that I had. You have a screen which will load up all of the details about an account/customer/order/whatever your system deals with. If you use a relational database (which most of you probably do), this probably means that you go and run a series of SQL queries (using an ORM or not) to load up all of the data that you need on the screen.

In my case, I had several slow SQL queries that had to run (and by slow, I mean ~2 seconds). The queries weren’t all that slow, but if you do 20 SQL queries and each one waits until the previous one finishes, you end up with it taking 12 seconds to load all of the data. Not good.

So what I did was to do each call as a Task and let the framework do it as fast as it can with as many available threads as possible. This is really easy to do, actually, once you learn a few basics.

Here’s a sample of what my old code looked like:

dto.Enrollments = EnrollmentRepository.GetEnrollmentsForAccount(accountId);
dto.Usages = UsageRepository.GetUsagesForAccount(accountId);
dto.Invoices = InvoicesRepository.GetInvoicesForAccount(accountId);
return dto;

(Obviously, I’m simplifying the code a bit for the sake of this post, there were about 20 calls in the real code.)

Here’s what the code turned into:

var tasks = new List();
tasks.Add(Task.Run(() => dto.Enrollments = EnrollmentRepository.GetEnrollmentsForAccount(accountId)));
tasks.Add(Task.Run(() => dto.Usages = UsageRepository.GetUsagesForAccount(accountId)));
tasks.Add(Task.Run(() => dto.Invoices = InvoicesRepository.GetInvoicesForAccount(accountId)));
Task.WaitAll(tasks);
return dto;

I really only added two things. Task.Run() tells the framework to do an action on a new thread. Task.WaitAll() tells the framework that the execution of the code should wait at that point until all tasks are complete.

With this simple change, I was able to take the loading of an account from ~12 seconds down to 2 seconds!

This is not the first time that I’ve written code that does things on multiple threads. But this is the first time that I did it and it was this easy. This is important because now it’s easy enough to make me think about doing things asynchronously more often. In the JavaScript world, doing things asynchronously is the norm (Node.js basically forces you do write asynchronous server code). It feels a little weird at first, but it makes total sense. If I have this fancy computer that has lots of hyper-threaded cores, why wouldn’t I take advantage of it? That would be like having an assembly line with 8 workers but then having one person do all the work while the other seven sat around and watched.

How much can I actually do at once?

This got me curious. I know that I have a quad-core machine, and the cores are hyper-threaded so each core can do 2 threads at once. This means that my machine should be able to do 8 things at once. I decided to find out what would actually happen.

This code will queue up 50 tasks. Each task will sleep for 1 second and then tell me when it finished.

[TestMethod]
public void How_many_things_can_we_do_at_once()
{
    Func action = i =>
        {
            return (() =>
                {
                    Thread.Sleep(1000);
                    Console.WriteLine("Task {0} finished at {1}.", i, DateTime.Now.ToLongTimeString());
                });
        };

    var tasks = new List();
    for (var i = 0; i < 50; i++)
    {
        tasks.Add(Task.Run(action(i)));
    }

    Task.WaitAll(tasks.ToArray());
}

Here's the output of the test:

Task 1 finished at 10:10:52 PM.
Task 2 finished at 10:10:52 PM.
Task 3 finished at 10:10:52 PM.
Task 0 finished at 10:10:52 PM.
Task 4 finished at 10:10:52 PM.
Task 6 finished at 10:10:53 PM.
Task 5 finished at 10:10:53 PM.
Task 7 finished at 10:10:53 PM.
Task 8 finished at 10:10:53 PM.
Task 9 finished at 10:10:53 PM.
Task 10 finished at 10:10:53 PM.
Task 11 finished at 10:10:54 PM.
Task 12 finished at 10:10:54 PM.
Task 13 finished at 10:10:54 PM.
Task 14 finished at 10:10:54 PM.
Task 16 finished at 10:10:54 PM.
Task 15 finished at 10:10:54 PM.
Task 17 finished at 10:10:55 PM.
Task 19 finished at 10:10:55 PM.
Task 18 finished at 10:10:55 PM.
Task 20 finished at 10:10:55 PM.
Task 21 finished at 10:10:55 PM.
Task 22 finished at 10:10:55 PM.
Task 23 finished at 10:10:55 PM.
Task 24 finished at 10:10:56 PM.
Task 25 finished at 10:10:56 PM.
Task 26 finished at 10:10:56 PM.
Task 27 finished at 10:10:56 PM.
Task 28 finished at 10:10:56 PM.
Task 29 finished at 10:10:56 PM.
Task 30 finished at 10:10:56 PM.
Task 32 finished at 10:10:57 PM.
Task 31 finished at 10:10:57 PM.
Task 33 finished at 10:10:57 PM.
Task 34 finished at 10:10:57 PM.
Task 36 finished at 10:10:57 PM.
Task 35 finished at 10:10:57 PM.
Task 37 finished at 10:10:57 PM.
Task 38 finished at 10:10:57 PM.
Task 39 finished at 10:10:58 PM.
Task 40 finished at 10:10:58 PM.
Task 41 finished at 10:10:58 PM.
Task 42 finished at 10:10:58 PM.
Task 43 finished at 10:10:58 PM.
Task 45 finished at 10:10:58 PM.
Task 44 finished at 10:10:58 PM.
Task 46 finished at 10:10:58 PM.
Task 47 finished at 10:10:59 PM.
Task 49 finished at 10:10:59 PM.
Task 48 finished at 10:10:59 PM.

The test completed anywhere from 6-8 tasks per second in this test run. I did other runs where it never got above 6 tasks per second. It all depends on whatever else my machine is trying to do at the same time that is tying up the cores. The good thing is that the framework is taking care of creating the threads, figuring out when a thread can run, disposing of the thread when it's done, and all of that plumbing that I don't have to worry about.

Learn more

I found a really good series of blog posts that covered all kinds of different topics related to parallelism, threads, tasks, async/await, and everything related to it. It's definitely a new way of thinking for me but I'm starting to think of all kinds of ways that parallelism is going to change how I write code.

I found this post that I wrote in 2010 and the 2014 version of myself can’t say it much better, so I’m going to regurgitate the same post for your reading enjoyment.

Go to a software conference near you and you will probably hear talks on new languages, new frameworks, how to design code better, how to test better, and the like. What no one ever seems to talk about is how you can go faster.

We need to get faster at what we do, because it just takes too long. Why do you think companies and managers are always pressuring people to get things done faster? This is a tricky situation though — the challenge is to find ways to get faster without cutting corners, ignoring unit testing, and writing poorly designed code. Anyone can get things done faster by deciding to not write tests or not think about how to design code well, but that’s cheating. That just leads to more bugs and more work down the road.

Don’t ignore the importance of getting things done in a timely manner. I got to be a project manager on a project once, and every day I was looking at our feature wall to see how we were doing and if we were on schedule. I guarantee that your manager or project manager is doing the same thing. That experience and awareness helps keep me from not wasting time adding non-essential features or spending too much time over-analyzing things (be especially careful of this one if you’re pairing). I try to work with a sense of urgency, as if I’m competing with someone else who is trying to complete the same project faster than I can (without cutting corners).

One way to get faster at something is to practice. Find a simple coding problem, like the ones mentioned here. Pick an easy one (nothing with crazy math algorithms, complicated recursion, etc.), or maybe take a complicated one and simplify it. Try and find something that you can do in 15 minutes or less, but still involves writing tests and creating multiple files.

The first time through, go through it like you normally would. Think about design, write good tests, and make sure you understand all the nuances. Then go back and do it again and time yourself. Do it over and over, and try to beat your previous time. At this point, you’ll know how to design the code pretty well, and in order to get faster you’ll have get faster at moving around your IDE, find ways to generate code, or learn new tricks. This is what you’re trying to learn. Remember, you’re not allowed to cut corners! You still have to write tests and write well-designed, readable, clean code. Check your code each time you’re done and make sure you didn’t compromise in these areas.

In sports, there are the teams that are good on paper and there are those who execute during crunch time. You may be good at writing well-designed, well-tested code, but if you can’t get it done on time, no one is going to care. So take time to hone your skills and become a faster developer.

When we write automated tests, we want to do it in the simplest way possible while achieving the highest level of quality for the time we invest in our tests. Unfortunately, this is easier said than done.

Writing tests can be hard. It’s hard figuring out what kinds of automated tests to write. We can write unit tests, integration tests, functional/acceptance tests, performance tests, or just do manual testing. We have to decide if developers are writing tests or if QA people are doing it (or both). It’s really complicated!

Let’s look at some ways that people sometimes tackle the testing problem and then discuss some different ways we can approach it.

The black box

On some projects, the team is testing a big black box. Usually this is where QA people are doing all the testing and developers aren’t writing automated tests. If you read my blog at all you know that I do not like this approach (unless time to market is really that important) because it leads to lots of bugs and makes refactoring anything really scary. In this scenario, QA testers typically only control the inputs and outputs into the black box (which is usually a user interface of some kind). This leads to problems like having to jump through a bunch of hoops just to test something that’s farther down the line of some complicated workflow.

Tiny slices

If you’re a fan of test-driven development, you will write a lot of unit tests. In this case, you’re slicing your application up into very tiny, testable units (like at a class level) and mocking and stubbing the dependencies of each class. This gives you faster, less brittle tests. You still probably have QA people testing the black box as well, so now we’re using two different approaches, with is good.

I’m not satisfied

While each of the previous two approaches have their positives, they both have their negatives. I’ve already talked about the negatives of all manual QA black box testing, so I won’t go into that again (although I’m always up for a good rant). But writing lots of unit tests has its problems as well. For example:

• Tests with lots of mocks and stubs, and failing tests that fail because someone refactored a class any now my stubs and mocks are all hosed. You know the feeling.
• Testing an individual class or method is great, but my tests aren’t always testing something that has business value on its own.

No limits

You own your application. Your application does not own you (at least it shouldn’t). We also own the testing of our application and should be able to test it in any way that we can think of. The goal is high quality, low cost of maintaining the test suite, and speed to market. How can we best achieve this goal? (And don’t just give me the first textbook answer that pops in your head.)

There is no one-size-fits-all method for testing applications, and there isn’t even one single best way to test a single application. So what if we used many different approaches and broke our system up into chunks so that we can use each testing method to its fullest potential?

In this case, I’m dividing up my application into separate modules, each with its own purpose, function, and business value. Some may have a user interface component and other might just do some task behind the scenes. I can decide how to best test each module individually. Maybe some modules are done with all black-box acceptance testing, and other modules are done with lots of unit tests. Even within the black-box modules, I might still write unit tests. Of course, I’m still going to have some end-to-end tests (manual and/or automated) that test the whole system working together, but I don’t have to test the majority of the functionality this way.

My favorite kinds of tests are ones that test a system working together because I can specify the inputs and outputs and I don’t have to deal with tons of stubs and mocks. Now if you try to test the whole application end to end this way, it can be a bit cumbersome. But if you have a smaller module that you can test end-to-end, now you can have clean, readable, well-defined tests that don’t have tons of mocks, and the tests define some business function that the module needs to perform. My module might still work independent from the UI or the database, so I might still be able to stub those out and have fast tests. This feels like the kinds of tests I’ve always wanted – tests that test a module end-to-end but are able to run fast because I can still isolate dependencies.

Hey, look, it turns out that modular applications is a good idea in general! It’s way easier to deal with lots of smaller applications that work together than dealing with one monolithic application. Those of you with large solution files and long compilation time (I’m raising my hand) know the pain of dealing with large applications.

The emerging blob

We like to talk about “emergent design” and that we can write tests first and let that drive the design of your code. That is true, but your codebase will evolve into a monolithic (albeit well-tested) blob of an application that assimilates all code into it’s large collective.

The only way you’re going to have a modular application is if you draw the lines in the sand up front. This can be really hard to do when you have a newer application and you don’t have a ton of insight to tell you how to keep things separate. Compounding the confusion is the fact that you might have a single database for the application as a whole, which I think is fine. You can multiple modules that use the same database, even the same tables. Sure, it would be better if you can keep the tables in separate databases, but sometimes that’s not possible or realistic.

You might start out with certain modules and then realize that you created a separation that is too painful to maintain. That’s OK, it’s much easier to combine two modules than it is it try and separate things into modules after the fact!

Once you’ve defined your modules, now you can decide how to test them (QA and devs should work together on this!).

This feels better

• Cleaner tests with fewer mocks that test mini-systems that provide some function or business value
• More modularity means I can change code without potentially breaking as many things
• Smaller solution files!

I really like how this sounds.