I tweeted a quote today that I found to be very insightful.
A poignant reminder of why I'm here. pic.twitter.com/H9Nkbnm4Qt
— Jon Kruger (@JonKruger) April 8, 2014
You could take this two different ways. I take it to mean that I need to just the right amount of testing in order to be confident that my code works and will continue to work.
You could also see it another way, as pointed out by some others:
@JonKruger I think the line which follows that quote is also important; as an industry, that level of confidence might not bee too high.
— Steven Harman (@stevenharman) April 8, 2014
— SeattleFan4Dan4 (@TJWilk_WA) April 8, 2014
There are those out there that think that testing is a waste of time and I could see some of them taking a quote like this and saying, “I’m a good enough developer that I don’t need tests in order to write code that works!” (I heard someone say those exact words once, sadly.)
@JonKruger Most developers do the same thing… they just have way too much confidence in their coding skills. ;)
— jared richardson (@jaredrichardson) April 8, 2014
The discrepancy is due to what the word “confidence” means in this quote. If it’s just confidence that it works now, then you might be fine without tests, but if it’s confidence that your code will still be working a year from now after someone else has had to modify it, then you probably want tests. (Heck, I want tests so that I can change my own code tomorrow!) I find that the problem is that on many teams, developers define confidence as “good enough that QA can look at it” and then achieving true “confidence” is someone else’s problem.
Maybe we should change the pronouns.
We (the team) get paid for code that works, so our philosophy is to tests as little as possible to reach a given level of confidence.
Now this changes things. What’s the best way to test as little as possible? Automate all the tests that should be automated. Let QA spend time doing valuable things like exploratory testing instead of doing loads of manual regression tests. Funny how you can turn everything on it’s head when you take what is perceived to be an individual’s problem and make it everyone’s problem!
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.
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.
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.
The “impostor syndrome“… is when you’re pretty sure that all the other coders you work with are smarter, more talented and more skilled than you are. You live in fear that people will discover that you are really faking your smarts or skills or accomplishments.
Ever feel like this?
If you do, you’re not alone. But this feeling is not healthy and probably isn’t accurate.
I know people who are like this, and you probably do too. It tends to manifest itself when people feel that they need to work extra hours in order to provide a perceived amount of value that matches the amount of value provided by people working normal hours.
Why does this happen? I believe it’s because people are comparing themselves to others (unhealthy) instead of looking at the amount of value that they do provide (healthy).
Look, if someone gave you a job or put you in a position, they did it because they see value in you and they think that you can do the job. You already convinced them that you can do it!
Now that you are past that point, let’s focus on the value that you provide. I’m guessing that you can probably come up with a list of value you provide at work. For example, maybe you can say that you’re a solid developer, you like helping users, you have a lot of knowledge of system X in your company, and you’re good at using ORM tools.
Think about the last time that someone left your company or your team. It was pain replacing them, wasn’t it? (Well, in some cases maybe that person leaving was a good thing.) But if that guy who left wasn’t a problem, it probably was a lot of work training someone new, learning all of the things that person knew, and trying to make up for the value that walked out the door. (As someone who just took over for someone who left, trust me, I know the feeling!)
Instead of comparing yourself with others, focus on what you’re good at and how you can provide more value! Come up with a plan of something that you want to do to provide value. Write down the steps that you’re going to take to accomplish it. Then when you make it happen, look back and enjoy the good feeling that comes with accomplishing something and providing value.
That’s what matters! That’s what your company wants from you. They don’t want you to be another (insert name here). They want you to be the best version of you that you can be.
These days most every workplace seems to be at least somewhat set up for you to work from home. Most places have a VPN where you can connect from outside the office, and flexible work hours are becoming more prevalent, especially for developers since they tend to spend less time in meetings and sometimes like to work at odd hours.
I am one of those people. I have young kids, which means that I tend to get in a little later than most people and I also leave a little earlier than most people. In order to pull this off and still have time to go to lunch occasionally, I have to work some at home, either at night or on the weekends.
Personally, I like this setup. It allows me to have more flexibility with how I spend my time, and if I need some guaranteed uninterrupted work time, I can get often get it at home. What I didn’t expect is the perception I gave people when I started doing this.
The new face time
It used to be that some workplaces would unfairly judge people by how much “face time” they put in it work (which I think is garbage, but that’s for another post). That seems to have lessened (at least at the places I’ve worked at), but now I have the capability to work pretty much anytime at home.
When I say I work at odd hours, I mean it. I’ve updated work items at 8:30pm, checked in code at 2am, sent emails at 6am, deployed stuff to test environments (which sends notification emails), etc.
The perception this gave people was that I worked all the time! People assumed that I was working 40ish hours a week at the office and then going home and working some more (and sometimes a lot more). This wasn’t true at all (I usually don’t work lots of extra hours), but I had multiple people say that they thought that I worked tons of hours.
What I do with my time is my business, so if I were one of those people who wanted to work 60 hours a week, I’d say that was fine because it’s my time and my choice. But it becomes a problem when my perceived work schedule affects the way people feel about how they spend their time.
The problem is that now other people on the team (particularly those who are new and want to make a good impression) feel like maybe they’re not doing enough if they’re not online doing work at all hours of the day. Maybe they feel like they need to put in more hours in order to be successful or even just fit in. They might start feeling guilty if they don’t log on on Saturday and respond to the email that I sent on Friday night.
This does not lead to a healthy work-life balance. I don’t want people to feel guilty about leaving work at work, or not taking their laptop home on the weekend. I want them to feel good about the time they spend at work as well as the time they spend at home. I want them to know that their hard work is valued, but that they don’t need to work loads of hours in order to be appreciated.
What I’m doing about it
I’m still going to work odd hours. It works really well for me. But in order to not give the wrong impression, I’ve started doing things differently.
- I almost never send emails on the weekend or at night, unless it’s responding to some kind of production issue or something that really needs my attention, or unless I’m sending it to someone who knows me and my work schedule. I especially avoid send emails to large groups of people at odd hours. I might write up an email, but I’ll leave it just leave it sitting there so that I can hit Send on Monday morning.
- If I want to check in code, I’ll commit it locally but not actually push it up to the server until I go into work. (This also saves me from breaking the build on the weekend and then having to fix it when would rather be doing something else.) Of course, you need a distributed source control system like Git to do this (sorry TFS users), but if you’re stuck with TFS, you can achieve this with git-tfs. You really should use Git anyway because it’s awesome, and you get huge benefits for something that’s fairly easy to learn.
- I try not and talk about working at odd hours when lots of other people are around. They might not know why I’m doing it, and it might give the wrong impressions about expectations. Too often it comes across as boasting that I’m in some way better for being willing to give up my free time (when in reality, I’m not giving up any more free time than they are, I just do it at a different hour).
Working at home is great, it can lead to some bad misconceptions and unhealthy team dynamics, so just be cognizant of how people might be interpreting your actions.
I was having a discussion today with some people at work who were reading a book that helps you determine your strengths so that you can take advantage of your strengths and be great at what you do. That led me to think that while knowing my strengths is a good thing, I also want to know my weaknesses.
When I was starting out as a developer, I remember reading up on how to interview well and potential questions that interviewers might ask. One of the potential questions that I saw listed in several articles was, “What are your weaknesses?” That question didn’t really make much sense to me, maybe because I didn’t really know how to answer it (“yeah, my weakness is that I work too hard”), and I didn’t really know what an interviewer might want to get out of it.
I’ve never had anyone ask me that question in an interview (and I don’t think I would ever ask it in an interview myself), but I think the reason that someone might ask that is to see if someone is aware of their own shortcomings and if they’re doing anything about it. So here are some reasons that I try to learn my weaknesses.
Knowing what roles to avoid
We all have things that we are good at and things that we’re not so good at. There are many different roles you can play on a software development team (or any team for that matter). Maybe you really enjoy coding and are really good at it. Maybe you are good at project management and coordinating multiple efforts in order to reach a common goal. Maybe you have strong management skills and can help your team members get better and achieve their career goals. Maybe you are good at helping teams adopt Agile practices. Maybe you’re good at talking to users and business people.
As you read that list, you probably thought of some of those things that you are good at and that you really enjoy doing, and maybe others that don’t get you so excited. This is really really important to remember so that you don’t inadvertently steer your career down the wrong path. The classic example is the developer who was really good at coding and was promoted to management and now can’t take advantage of their strong development skills that got them there in the first place. On the other hand, I know some developers that went into management and thrived there. Either one is fine, but you’ll be happier and more successful if you can stay in a role that emphasizes your strengths.
Knowing what to work on
Some things will come naturally to you, and other things won’t. That doesn’t mean that you should only do things that you’re good at. Most developers naturally are not extremely gifted when it comes to talking to users and business people, but I think this is a very important skill that I think every developer should work hard at. Being able to right good code does you no good if you can’t create systems that will actually solve the right problems.
This is why most meetups that I attend have more to do with QA testing, business analysis, and project management. I’m better at development than I am at all those things, and I like development the best, but I want to be better at the other disciplines because it makes me a more well-rounded developer and allows me to know how to help entire teams instead of just developers (which lines up with my career goals).
We can develop these skills if we work at them, even if they don’t come naturally. But if you don’t take the time to look at what you need to work on, you won’t ever get better.
Knowing how other people might see you
There are two sides to this one. First, I want people to know me for my strengths. There are thousands of .NET developers, agile coaches, project managers, etc. out there. What is going to separate you from the crowd? What you’re great at.
That will get you in the door, but if you stay somewhere long enough, people will find out what you’re weaknesses are. This is fine, but I want to be aware of how people might be viewing me because that might help me understand the way that people act towards me and why they might make various decisions that affect me. If I’m aware of my weaknesses and other people also have discovered those weaknesses, now I can take what they say and understand more about what they are saying and what is causing them to react a certain way. In turn, this teaches me more about myself and what I need to work on in order to get better. (At no point should I ever beat myself up for my weaknesses, this has no constructive value for anyone.)
For example, I am an extrovert, which is a minority in the software development world. This means that I sometimes tend to think out loud, and sometimes I’ll throw ideas around without having really thought them out. I think this sometimes confuses and overwhelms some of my other team members, who were still trying to understand my previous thought which I’ve already moved on from. While this is the way that I tend to process ideas, I’ve realized (based on how other people have reacted) that this isn’t always constructive for others and that I sometimes need to think things through more internally before I verbalize them.
While thinking about your weaknesses isn’t always a whole lot of fun, it will go a long way towards bringing you career success and enjoyment. We could all use a little more of that.
The open team workspace, once limited to hardcore Agile enthusiasts, is now becoming more mainstream (dare I say trendy). Tall cube walls are being torn down in favor of short walls, folding tables, rolling desks, and any number of other creative setups. But some people are wondering if it’s a good thing.
I’ve been working in open environments for most of the last 8 years now. I had L-shaped desks, folding tables, low cube walls, no cube walls, and everything in between. I’ve been a huge fan of this sort of setup, but I’ve worked with some people who didn’t like it as much. This is what I’ve got now (which I really like):
Regardless of whether you like open workspaces or not, there are some things you need to learn in order to work in this sort of environment. If your company has an open floor plan, there are definitely some considerations that you should think about.
The #1 complaint I hear from people who don’t like open workspaces is that it is hard to focus. Sometimes when you’re working on a difficult coding problem, you need solid time to focus on one thing and one thing only. This is really important, but thankfully there are many ways to handle it.
This one is pretty obvious. I often joke that our IT department sounds like the mall food court. We are by far the loudest department in the company (excluding departments where people are on phone most of the day). All of this is good but you need a way to block out the noise.
Everyone in our IT department has a laptop. That means that we can work at our desk, or we can go work in the lunch room, the coffee shop, or at home. We have some docking stations set up with monitors in some rooms where you can work by yourself, or collaborate with your friends. We have conference rooms with big screen TVs and whiteboards. We can draw on the windows with dry erase markers. I’ll often go sit somewhere else in the building, which I like to do if I’m going to work on something that requires a lot of creativity just to get a change of scenery. We have rooms that look like this (no this is not a stock photo):
I have young kids, so I tend to get in a little later, leave a little earlier, and work some at night after the kids go to bed. I can kick off a job at night before I go to bed and it’s ready for me to test in the morning. The flexible hours allow me to do some of my work at home when no one can bother me, and I still have plenty of time with the team. It’s the best of both worlds.
Keep teams together… and separate
I love the collaboration, camaradarie, and togetherness that comes with an open work environment. I’m a people person, so I thrive on the energy. Working from home can be nice but I love seeing people every day. I love that I go into work and people ask me how my weekend was.
At the same time, if you’re going to have an open floor plan with several different teams in the same area, you do have to be careful about putting different teams too close together. We have lots of teams in one area, but I’m friends with most of them, so it’s not a big deal. And while our environment is very open, it’s not like we’re crammed onto rows of folding tables like we’re in a computer lab. I still have my own personal space. I like the sound of my teammates talking and collaborating, but the sound of people that you don’t know is like fingernails on the chalkboard. It can drive you insane.
The common thread
After years of hearing pros and cons of open environments, I think I’ve found the common thread that most people will agree on. We need work environments that meet multiple needs and many different situations. Sometimes you need to collaborate, and sometimes you need to focus by yourself. Sometimes you need to look at code with a group of people, and sometimes you need to draw things out on a whiteboard. Sometimes you need a place that helps inspire creativity. Some people thrive around people, and some people need peace and quiet. Some people like working during the day, and some people like working after midnight. There are ways that we can provide work environments that provide the best of everything and allow people and teams to work in whatever manner works best for them.
I believe in open work environments because we are solving business problems, and the hardest part of every software project I’ve been on has been not having enough communication. Sure, there are difficult technical problems, but those are best solved in the context of the team, even though much of the actual work is done individually. Tall cube walls tend to decrease communication when we usually need to increase communication. In an open environment, the communication barriers are broken down (literally), but I still have ways that I can get away and focus.
We need to remember that people are all very different. What’s good for one person may not be preferable to another, and we need to be aware of that.
We all love the DRY principle (Don’t Repeat Yourself). It really is a good idea, we don’t want to have two places in the code that do the same thing, and we want good object-oriented design. But even DRY can go too far.
Recently I’ve run into some cases where DRY decreases the readability of the code. I had some simple classes to write that do some relatively simple calculations, and the business rules are fairly similar to some other classes that exist, but with a few differences. I started down the path of making one class that can handle all situations, with hooks for modifying the behavior of the class (either virtual methods or configuration settings somewhere else).
This is all well and good until you realize that now you’ve taken something simple and turned it into something really complicated that even you have a hard time understanding anymore.
DRY is great, but I lost sight of why DRY is good. DRY is good because it makes code more maintainable, more consistent, and easier to understand and add new functionality. But as soon as DRY stops providing those benefits, maybe it’s time to keep things simple and just write readable code that makes sense, even if it means you have a little bit of duplication.
There are lots of code katas out there that are typically used to help developers practice test driven development and writing well-designed code. I have a new kind of kata for you today.
In my last post I talked about how developers should be able to test their own code, but as developers we need to get better and defining all of the test cases. The only way to get better is to practice.
Testing a four-function calculator
Let’s say you need to test a basic four function calculator like this one.
What are all of the testing scenarios? Keep in mind that just from looking at the picture, you might not know the exact requirements of how the calculator works without asking some questions.
Some basic details (for those of you who are too young to ever have used one of these calculators):
- Pressing M+ will add the current value to the value stored in memory (or 0 if there is no memory value), but not change the value on the screen
- Pressing M- will subtract the current value to the value stored in memory (or 0 if there is no memory value), but not change the value on the screen
- Pressing MR will load the current memory value and display it on the screen
- Pressing MC will clear the current memory value, but not change the value on the screen
If you don’t know how something should work, write down the question that you need to ask or record the assumption that you made about how it should work (so that you could validate the assumption later). You’re also allowed to try things on your computer’s calculator to see how something should work (in real life, we often look at other implementations of our software to get ideas about how it should work), but remember to write down your assumptions so that you can validate them.
Come up with your test cases, questions, and assumptions and post your answers in the comments. You can use any format for the test cases that you would like. Let’s see what you can come up with.
There are those who believe that a developer should not test their own code. This may sound logical, but I’m not sure I’m buying it.
This statement typically refers to QA testing, and doesn’t mean that a developer shouldn’t write unit tests. The thinking here is that a second person testing the features that you’ve developed might think of things a different way and find a problem that you didn’t think of when you wrote the code.
There are lots of commonly accepted statements and ideas like this in software development. But I’ve found that in many cases, these ideas are usually based on certain assumptions, and if you can challenge those assumptions, you might open yourself up to things that you didn’t think were possible.
The assumption that I see here is that a developer writing the code is not sufficiently capable of thinking of all of the test cases. Imagine you write code for a feature, and now you have to test it. At this point, you’ve gone through a certain mental thought process when you implemented the feature. This makes it much harder to think outside of the box to come up with the edge cases. Not to mention that when you see that the feature appears to be working overall, it’s really really tempting to do some basic manual testing and then move on to the next feature without really doing your due diligence. A independent QA tester, however, will look at the feature objectively because their thought process isn’t clouded by past experience of having written the code.
OK, so what if the developer figured out all of the tests cases before writing the code? Now their thinking isn’t clouded by the implementation of the feature because they haven’t wrote the code yet. Maybe a QA person helps define the test cases, but this post is about developers testing their own code, so let’s assume that QA people aren’t involved. I would argue that now we’ve removed the main reason that developers are not good at testing their own code (thinking of the test cases after writing the code), so they should be able to think of test cases just as well as a QA tester, and therefore they should be able to test their own code.
Don’t misconstrue what I’m saying there – I’m not saying that we don’t need our QA teams. I’m saying that developers need to be responsible for testing. QA teams can add more testing help, but developers need to be responsible for their own code.
This opens you up to new possibilities. It enables developers to be confident about the quality of their code. It limits the wasted time you incur when you have the back-and-forth that comes with QA finding bugs and developers having to go back and fix things. It can reduce the amount of “checking” that QA people need to do because they might be comfortable knowing that developers are writing quality code.
If you’re a developer, this is some thing you can start doing today. Before you implement a feature, come up with all of the test scenarios before you write your code. If you have a QA team, have them review your test cases to see if you’ve missed anything. Then go write some bug free code!
How much of the responsibility for the software that you are creating falls on your shoulders?
There are two ways of looking at responsibility on a team. One view would be to say that if there are 10 people on the team, then I’m responsible for 10% of the software development process. I don’t need to be concerned with the quality of the requirements because that’s the business analysts’ job. I don’t need to worry about testing my code because we have testers to do that.
The other view is that even in a team environment, I am still 100% responsible for the software I’m creating. That means that I’m not just implementing the requirements, I’m trying to understand the requirements to make sure that they’re correct and that we’re building things in the best way possible that will meet the needs of the business. And that certainly means that I’m never ever going to send code to QA that I haven’t tested just because I think they’re going to test it for me.
I need to be responsible for communicating with my team members the best that I can. I would much rather be clear about who is doing what rather than assuming. If I make an assumption, it’s probably going to be wrong – either I will assume someone is going to do something when they’re not and something will slip through the cracks, or I will assume someone is not going to do something when they are, and now we’ve duplicated effort.
This is what I see happen often on software teams, especially when it comes to testing. Developers assume that QA is going to do the testing, so they give code to QA without completely knowing if it’s working. QA assumes that developers are going to do this and don’t know what was tested and what wasn’t, so they think they have to test 100% of the functionality of the feature. In reality, the developer probably wrote decent code that mostly works, and they probably did test it to some extent (whether manual or automated), so the tester is duplicating some of the effort, but if they don’t know what was already done, they don’t have a choice.
This is where communication is key. If I as a developer am going to write automated tests to prove that my code works, then I want QA to be involved in the writing of the tests (even if that’s just reviewing what I’m doing). That way QA doesn’t have to duplicate effort because they can know that developers have already done some of the testing, and developers can start giving code to QA when they are confident that it works (with actual proof to back it up). QA and developers can work together to decide who is going to test what, what is going to be tested, and how it’s going to be tested.
In this case, everyone is 100% responsible for the quality of the software. Instead of expecting others to cover for us, we work together with others to make sure everything is covered. This requires people to move past their traditional roles, trust each other, and work together. In the end, we won’t duplicate effort and we won’t let things slip through the cracks.
Older Posts »