Can Tools Make Coding Too Easy?

Code Generation ToolsI caught a wonderful article on Dzone today by Jonas Gauffin titled “How Resharper rocks my average work day“. In this article Jonas talks about a tool he uses regularly called “Resharper” that makes common tasks a bit more automated when coding in C#. This article reminded me that we are continuously developing better and better tools that help us write code. But is there a point where we are going to go too far? If you think about it, in a bit of a paranoid type of way, this might even be the beginning of computers writing code on their own without us. For fear of being labeled as some kind of Amish coder who is stuck on the ways of the past, I assure you nothing is further from the truth. I do however like to reflect from time to time on where we are going in our coding evolution.

There is something to be said for doing it the long way

You will be hard pressed to find a programmer who won’t admit that coding can be just as much of an art as a science. I for one believe that only the legendary among us will be those who are just as creative in problem solving as they are a scientist following the scientific method with programming. This artistic side of us is much like being a wood worker who carves masterpiece sculptures out of wood (we use code). This wood worker has a set of hand tools, and perhaps the occasional use of a chain saw, which they use to carve every curve and shape every surface until they have their vision realized. It is a long age-old process but some of the best work takes awhile and is hand made.

Sure there are electric tools like sanders, saws and drills but this wood worker prefers to use some of the tools of the past to create something unique and one of a kind. More importantly, they practice their craft as they do it. They gain experience which they will take into their next project and eventually becomes a master. Much is the same with programmers. I think we need to keep using the basic tools even if there are perhaps a few tools that do everything for us. We learn this way and if we continue to have tools that do everything for us we will eventually be writing programs where we know as little as 10% of what the code does. When problems arise, now what? Call in the specialist! Yeah the guy who is surgical and probably writes this stuff by hand.

Code generators vs the human mind

I often think we should be looking into tools that advise us versus generating for us. One of the things that Resharper looked like it was doing was generating syntax and plopping in code. Now I could be wrong about this, but I have seen tools that do just that. Granted Resharper was asking questions to confirm what we wanted to do and gave us a few choices. But what I have discovered over the years is that these tools slowly make us lazy and not want to think. I have had quite a few programmers come to me asking about code that was written by them… well was actually written by their tools. Then of course at the first sign of major trouble they have no clue where to find the bug, it was all generated.

Most of us roll our eyes when we see someone come to us with code generated by Dreamweaver. We already know that the generated code is not up to snuff and is often full of useless div tags or styling that almost contradicts itself. This is an extreme case of what I am talking about, but tools that do things for us automatically should always be met with skepticism or at least peer reviewed. I guess what I am asserting here is that tools that automate too much make us lazy and stupid simply because we often don’t take the time to understand everything it did. We are already off to the next function or the next project. At least it got rid of the red squiggles right?

Write some things by hand, even if it takes longer

Should we go back to using a text editor only and compile through command lines rather than IDEs? No, but what I am saying is that you should take the time to write a bit of code even if it seems mundane and takes longer. Going through the basics of writing code by hand helps keep concepts sharp in your mind and help you understand their role in software design. If you are doing things properly you should find that most code you write you are writing once (DRY principle) anyways and at the same time you reinforce what you know. It may take longer for you to do it now, but at least when a generator breaks down in the future, your hand craftsmanship skills will be strong enough and you can get in there and fix it. I have written a lot of tedious and time consuming code that might have been done instantly through some automated process, but at least I know what it is doing and with enough practice I will still have enough time to help you with your broken generated code.

Thanks again for reading!

About The Author

Martyr2 is the founder of the Coders Lexicon and author of the new ebook "The Programmers Idea Book". He has been a programmer for over 17 years. He works for a hot application development company in Vancouver Canada which service some of the biggest telecoms in the world. He has won numerous awards for his mentoring in software development and contributes regularly to several communities around the web. He is an expert in numerous languages including .NET, PHP, C/C++, Java and more.
  • http://soundythingie.net hansi

    i absolutely see myself more as a wood worker than as a scientist. However, to me the real interesting challenge is picking the right tools, the right language, the right abstraction level to hit a problem perfectly (and, to be fair, it hardly ever works out completely perfectly).
    I wouldn’t agree with your premise that writing things by hand makes you a better. In fact, i’d argue that you are actually suggesting over-thinking of problems where you (!) are interested in the solution.

    Don’t be scared of not understanding everything, it’s more human than understanding everything :)

    • http://www.coderslexicon.com Martyr2

      Well as I said in my article, specialists typically make a killing off that sort of thinking. I think we should be scared of not knowing everything our tools do for us… or at least most of what it does. Understanding the roots of where a tool is coming from helps us make better programs. It helps us appreciate our tools and what they are doing for us. Like everything in life those who rely on the system and don’t ask why the system exists are eventually the ones that end up being controlled by the system. I know for a fact that understanding a bit of the underlying technology behind our tools makes us better programmers. I am not saying not to use tools. We should just understand what they do for us in the eventuality we can’t rely on them. :)

  • Ken Whitesell

    The whole art of computer programming through the years has been an exercise in raising the level of abstraction at which programmers work.

    Following your train of thought to its logical conclusion, you’re saying that every programmer should spend some time writing in assembly language just in case their compiler fails. Or, how about hand coding in machine language if the assembler fails? What about toggling switch to set memory? …

    My point is, over time we’ve continued to build layers of abstraction over top of more fundamental principles. We don’t work at the same level as we did 10, 20, 30, 40 years ago. (At least those of us who have been programming for 40 years. )

    Yes, in the beginning of each evolution, there is a window of time where the new tools are unreliable, and some amount of “bridging knowledge” is required. But as the tools improve, that knowledge gradually loses its value – and that’s a good thing!

    Yes, there will always be a need for people comfortable with working at the lower layers. But I think it’s a mistake to assume that everyone needs that experience or knowledge.

    I started out at a time when 300 baud was “high speed” – 110 was routine. You better believe that we designed transmission protocols for efficiency. Figuring out how to optimize an 80-column card image was critical. Now, I ship *megabytes* of XML between systems without giving it a second-thought.

    Do I care that most of the programmers I work with wouldn’t know how to code a format card for an IBM-029 keypunch? Or punch an IBM 3211 carriage tape? Not in the least. So, following that same logic forward, in another 10 years, do you really think anyone is going to care *what* generates your html? I hope not.

    • http://www.coderslexicon.com Martyr2

      What I am saying is not to step back in the evolution of our abstractions or our thinking. I am just saying that we should personally take responsibility to do a bit of the work we leave to our tools to ourselves instead. I wouldn’t expect people to go back to the days of punch cards or anything like that, but we should be able to write our own properties and methods to a class without a tool doing all that work for us. Maybe try to write an indexer or overload an operator on our own just as practice for “muscle memory”.

      The building of our abstractions is fine and we should continue to move that direction as long as we programmers could also do it ourselves. The dangers we run is the fact we get to a level of abstraction where we eventually find ourselves struggling to even understand those abstractions. We have people using tools that they don’t really understand what they are doing for us. Classic example… the script kiddie. :)

  • http://blog.schemaczar.com Andrew Wolfe

    Structured metadata is better than generated code.

    This is an excellent topic. Generating code is a little dicey – what happens when you upgrade your generator? You’ve generated snippets into 75 files. You hand-tweaked these in 50 forgotten places. Then you realize your generator was buggy. How do you recover?

    Oracle JDeveloper generates reams and reams of code – Java, flavors of XML, WSDLs, Groovy and who knows what – and a lot of it works really well! (OK, I have friends who have worked on it.) But many experts would have trouble understanding the contents of those files.

    This is another reason I would retitle this discussion as “Code Generators Considered Harmful.”

    Why did you write the generator anyway? Because you found yourself coding the same pattern repeatedly.

    What do you do when you code a pattern repeatedly? You create a subroutine.

    What happens when the parameters or variable parts you code don’t look like things you can make subroutine parameters? You create a (C++ macro or another kind of) generator.

    Unfortunately at this point you haven’t really captured your abstraction. Instead you’ve approximated it with boilerplate and hand-coding.

    Where I try to go with this is not to generating code but to creating structured metadata. The logic in your generator and your runtime goes into interpreting the metadata. You can change the metadata content independently of the interpreter/executive. You can debug or upgrade the metadata. This is what I would propose as the better place to go.

    And you can still satisfy your coding urge by refining and improving the metadata executive code.

    • http://www.coderslexicon.com Martyr2

      Another great point. At least with metadata you get a little more control without killing the power of the automation. You don’t change the machine, you just develop better mechanisms that control the machine. Either way I still think it is important, and one of the main ideas to my post, that you going through some of the motions from time to time will help keep things fresh in your mind as well as help you learn and grow. Generators I think kill that a bit. Perhaps metadata is one step in the right direction. Thanks for the input Andrew. :)

  • http://www.easy-bins.com s clark

    The worst part of languages is the syntax. I have all the flow and logic skills, but the syntax is something I no longer care to memorize. Tools that. Haidle that tedium will get my dollars.

  • abhinaw

    Agree 100% with the author. Tools are just extra programing. People spend more time in understanding the tool and then lost in how to use that tool. They do not have time to focus on the business logic.
    Another thing i notice is that tools are over complex because theu are written for generic use.

    • http://www.coderslexicon.com Martyr2

      You are right. That is a whole other discussion. The fact that we also develop tools which probably have too much feature creep because the creator wants it to be everything to everyone. Very generic and in that may not solve any particular problem good enough. :)

  • http://nileshgr.com/ Name*

    Totally nailed it. IMO, generators should be used, but sparingly. There’s no way except writing raw code to understand stuff actually.

    PS: Get a mobile theme for your blog.

  • http://enterprisedevelopers rico

    I like this article. I tend to agree with the author. Code generators can be quite an achilles heel especially when we have customers that find a bug which we, the coders, didnt even write. I preach to my co-workers that if they are going to use code generators, they should understand fully what they are doing and why. I do however believe in the basics, Eclipse with a few nice plugins, hibernate tools for example, and I do enjoy a sprinkling of MySql workbench as well. Beyond the basics I often find myself at the bottom of the rabbit hole.

    • http://www.coderslexicon.com Martyr2

      For sure, we should continue to use tools that make our jobs easier. If we just take a minute to understand what they do for us and make sure they don’t do TOO much for us, then great. I would hate to do a lot of repetitive tasks but sometimes I do a bit of it just to help keep me sharp, grounded in what we are actually doing and practice makes perfect. When we use tools that do everything we are no longer practicing. Thanks for the reply, it is appreciated! :)

  • http://www.rossbencina.com Ross B.

    I have nothing against power tools, but I find it difficult to get critical distance when sitting at an editor. It’s easy to get stuck in a hack-pray-compile-fix mindset (at the extreme TDD promotes this mode). Clarity of architecture and design can require clear thinking about refactorings spanning tens or hundreds of classes/modules. Lately I find it better to spend time away from the computer with pen and paper, mapping out designs, considering configurations with a combination of textual stories and UML diagrams. It’s amazing how much clear space, paper and a good pen can free your mind.

    • http://www.coderslexicon.com Martyr2

      Then you my friend are not alone. Good developers should be away from the editor drawing things out from time to time. You are practicing your craft and thinking about design. I hope more people find their way to better systems by actually thinking about the problem than hacking their way through it and using a generator to “fill in the gaps”.

  • http://www.rossbencina.com Ross B.

    > If you are doing things properly you should find that
    > most code you write you are writing once (DRY
    > principle)

    Maybe I miss your point, but I don’t quite agree with that characterization of the DRY principle. To me DRY means that the code shouldn’t repeat the same logic — that’s not synonymous with the code being closed against changes. Often it’s quite the opposite: you find that you’ve written the same thing in multiple places and refactor to combine repeats to remove redundancy; or you generalize something so it can be used in multiple places. Both examples involve repeated re-writing of the same code so that it better fits into the scheme of your program *and* avoids repetition.

    Of course this is an excellent justification for not using a generator: if you want the code to be a clean and compact fit for the program, not just a jumble of generated boilerplate cruft then of course you want to write it by hand.

    • http://www.coderslexicon.com Martyr2

      I think you misunderstood. I am not at all saying that the DRY principle would be synonymous with “closed against changes”. What I am saying is that if you are doing things correctly (good design) you find yourself not repeating any code so won’t find yourself having to make as many refactors as you would for something generated. Generators often repeat themselves. They would generate 50 lines, each adding something to a listbox than perhaps using a loop that iterates 50 times. DRY is not just logic, it is simply the code itself repeating. Don’t write the same statement 50 times… refactor it!

      The second half of your statement is dead on and I think you are on the right track with things. I think we are saying the same thing other than the misunderstanding on my DRY comment. :)

  • Pingback: Darker Nemesis’ Weekly Reading (#9) | Darker Nemesis()