You Are Not Paid To Write Software

I saw the phrase “I’m paid to write software, not tests” recently, and it drove me up the wall crazy. I hate this phrase and all of the misleading, misinformation that it spews. This phrase is not only false, it’s fallacy. To suggest that we pit software against tests in terms of what we are paid to do… there is no logical path for this dichotomy to exist.

We, as software developers, are not paid to write software or tests. We’re paid to solve problems and provide solutions that either reduce cost or increase value/revenue for a business. We happen to do it through software, and writing tests is part of writing sustainable software.

Consistent And Reliable

I’m paid to solve problems consistently and reliably, and either implement the solutions through software or recommend a solution that doesn’t involve software. If I solve a problem once, but the solution breaks or is not repeatable after that one time, I have not done my job. If I solve a problem 100 times, add more code to try and solve a second problem and end up breaking the first solution, I have not done my job. My job is done when I can consistently and reliably solve the problem in a manner that either adds value or reduces cost.

Mechanics

Writing software is the simple, mechanical part of what we do. A machine can write software. In fact, that is what we end up doing most of the time – a compiler or interpreter is used to take abstraction and code that a human can understand and produce the software that the computer can understand.

Go, Solve Problems

You are not paid to write software or tests. You are paid to solve problems and you happen to do it through software (and tests).


Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs SignalLeaf.com - the amazingly awesome podcast audio hosting service that everyone should be using, and WatchMeCode.net where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in AntiPatterns, Business, Philosophy of Software, Pragmatism. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • msarchet

    Great post Derick.

    I think this is something that shows up in a lot of different things than just writing tests. As you pointed out were really paid to solve problems that add a net value to a business. Something that I see frequently is the ‘fixing’ of bugs that are an addressing of the symptom of a bug and not actually fixing the underlying cause of a bug. A good example of this is scripts that exist to fix bad data, when the data is bad because of lack of proper business rules or validation. Instead of fixing the business rules or fixing the validation the data is updated to solve a problem, which crops up again a day later after the same events occur.

    To me this is as unprofessional as going to a mechanic because your car is leaking oil and they put more oil in your car only to have all the oil leak out again. No one would believe that this is an acceptable practice, but in some companies the quicker solution is okay, until everything blows up.

    Tests to me are a vital part of software development, they force us to be able to prove that we both understand the scenarios that we are know about and to show that we have addressed them within the best of our ability. Whether those scenarios are a complex business rule, or a handling of potential errors, merely providing just code is usually not enough.

    This is not to say that bugs should never exist or we aren’t doing our job correctly, but if we aren’t doing our best to minimize those bugs and to prove that we are providing reliable software we aren’t doing our jobs correctly.

  • http://twitter.com/craigrbruce craig bruce

    how do you know your code works if you don’t write tests? I don’t get it.

    • http://twitter.com/fernandozamoraj fernandozamoraj

      You don’t. It’s called the code and pray approach. I hate that approach.

    • http://www.facebook.com/cribas Carlos Ribas

      The same way you know your tests work. Or, are you writing tests without writing code?

  • Timur

    This is EXACTLY the point I am trying to to make other developers around me understand. Its not about how technically innovative, complex or cool your software is. its not about how good your class structure is or how many unit tests you have. It is about whether you solved the problem well and will the solution be supportable for the time it must exist. To solve it well you need to have a technically good solution. To prove that it works, you need unit tests. To make it supportable it must have a good structure. But those are more of tools to do your job of solving the problem. They are not the actual reason for you to be there.

    Business users usually care about the solution and not how it is solved. Same as when I go to a car mechanic, you don’t care about the brand of oil he puts in, as long as I know its the right one for my car. I also don’t care about how many things he checked on my car. I do care that I don’t have to return to him for the next 5K miles until the next oil change.

    Timur

  • nerdklers

    Well written, what you could do is change it to “I get paid to write software that works as intended”. Then writing tests becomes a big part of it.

    • http://twitter.com/spye Steve Pye

      But even that takes “solution” out of the question. Writing software is a part of the process… understanding need, developing solutions, and when needed, writing software to help fulfill those solutions is a much larger process, and is really what a developer should be paid to do. If we’re doing our job well, we’re only “writing software” if it’s absolutely necessary.

  • http://twitter.com/MostlyHarmlessD Dom Barker

    When building an aircraft, you don’t just bolt the wings on and hope for the best. You test them to make sure that they don’t break. You do so because the consequences of the wings breaking would be dire.

    We shouldn’t be any less rigorous just because (generally) people don’t die when code breaks.

  • http://www.facebook.com/wmolina Wayne Molina

    The reality is a lot of developers are ignorant of “that testing thing” and feel testing just takes longer. I was fired from a developer job I had for almost 2 years because I was trying to push the team towards not necessarily TDD but doing some kind of testing beyond just poking around the app in IE, and tried to introduce software craftsmanship concepts to improve our code. The company decided that they just didn’t care about that stuff and wanted fast solutions, and let me go. To be honest I have yet to find a company that actually embraces those things or has a team that understands and cares about more than just slopping code in a code-behind file somewhere and calling a task done.

    • http://www.sixgun.co.uk/ Antony Scott

      I am saddened by your failure to find such a company. I left my last employer because of their refusal to even try TDD. The company I am now working for actively encourage testing and its now seen as an essential part of our daily work. I sometimes have to work on legacy systems and always feel a bit uneasy when I have no tests backing me up!

      • http://www.facebook.com/wmolina Wayne Molina

        I live in a very non-technical metro area (although you wouldn’t think that at first glance), so most companies that I interview with are basically like “We just use WebForms and stored procedures” like it was pre-2005; no Model-View-Presenter type of pattern, just code in event handlers. So far I’ve been the only person on the team and in the entire company that even knows what TDD is (same for other good things like ORMs, IoCs, the SOLID principles, etc.) let alone when you’d want to use it. Really thinking of getting out of development since I’m so tired of getting that “deer in the headlights” look from my teammates when I ask about what ORM they use or how they test code.

  • http://twitter.com/DaveVdE Dave Van den Eynde

    I get paid to read your blogposts, among other things.

    • http://mutedsolutions.com Derick Bailey

      lol :D

    • RagsOnWeb

      I get Paid after reading his blogposts :) Hats off to Derick

  • http://twitter.com/ChrisEdwards357 Chris Edwards

    So true. Writing tests results in working, maintainable software…well, in most cases. That’s what they are paying you for.

  • Guest

    from test driven development
    to feature driven development
    to _value_ driven development!

    even better, measurable_value and so money driven development!

  • Rasmus Bækgaard

    Word!
    You said it :D

  • gconz

    “Writing software is the simple, mechanical part of what we do. A machine can write software.”

    I hadn’t realized we had reached Judgment Day. When did SkyNet become self-aware?

  • Nathan Alden

    Am I really having to point out that yes, software developers are actually hired to *shock* develop software?!? Nooooo, I coulda sworn we were hired to “solve problems and provide solutions” (whatever that means). How much more markety can you make this sound?

    Software developers are hired to write code whose output–a product or service–can be sold at market for a profit. It’s that simple. You can call your job whatever you want and call what you do whatever you want, but that’s not why an employer hires you. He hires you to, yes, shut up and code–although some are nicer about that than others.

    The vast majority of software developers are not hired to solve problems where we happen to write software. We are hired with the express purpose of writing software that follows a business plan designed to make money.

    • http://mutedsolutions.com Derick Bailey

      lol – you said exactly the same thing i did, but thought you were saying something else. :D

    • http://www.Marisic.Net/ dotnetchris

      Nathan,

      “Software developers are hired to write code whose output–a product or service–can be sold at market for a profit.” That is not a software developer that is a programmer. Programmers are more like machinists, or mechanics, they don’t develop the ECU reading device and tester that really tells them what’s wrong, they just plug it in and use blind faith that it’s correct. The need for programmers in the future is going to massively dwindle. In a relatively short period of time we will hit a technology stand point that we will no longer need programmers to push bits around that everything will be done at a higher level about defining services, data models, workflows and the grunt work of marshaling bits around and mapping x to y will fall by the way side.

      If you’re a programmer, be very fearful of your career longevity. You are a cog in a machine, nothing more.

      I would rather be the person who formulated and placed the machine into existence to start with. And that’s why I am. That requires solving business problems inherently, not do X, do Y as your business says. It’s the whole do as I mean, not as I say. A business is not capable of determining software needs, they’re a business it’s not their job to, that’s my job.

  • Brian

    Logically, it seems that there’s an boundary around which writing tests doesn’t make sense. In certain industries, you’d create tests for your test system before using it to test a design. There’s a closure problem there: At some point, we have to decide that we have confidence in the techniques that we’re using, and just move ahead.
    The critical considerations in reaching closure involve time horizons well beyond the act of creating code. Are we creating an asset that our organization will re-use? How frequently will a feature be used, and what are the consequences of its failure? Will a customer refuse payment if this feature doesn’t work?
    Over the years I have found that my work process often involves mimicking an organization’s behavior until I understand how it creates pain for them, and then building assets quietly behind the scenes, with appropriate test development, to create assets that eventually let me code circles around my peers. Often those tools involve some level of automation of the code generation process.
    Does my management understand why this works? No. They are businessmen, which means that they take a practical attitude about resource acquisition and profit generation. If the have a candidate pool of people that only know how to exploit software assets (rather than create them), then they will figure out how to make money by exploiting the exploiters. We need to be fairly cautious about trying to change the culture in such environments. Emperors tend not to support those that reveal their nudity.