What does "easy" mean? To a code monkey, it's "press this button and 100 lines of code will dribble out". To a smart programmer, it's "Lisp macros let me change the language so I can code right to the problem domain".

Things like arbage collection make life easier, and it is a benefit to everyone (but a few real-time coders). Things like generics make life feel safer for people afraid of dynamic typing, but they just get in my way. As Dave Thomas once said, "All this pseudo-template stuff is just fear dressed up as syntax."

I don't see how the difficulty of writing C++ benefits anybody. It makes coding harder, testing harder, and understanding (and therefore maintenance) even harder. If I'm reading code, I want to understand what and how the problem is being solved. I don't want to have to decode each line of code that uses generics. I want the code to read "naturally". By that, I mean "close to the problem domain". I'm thinking of Rails code, where the Ruby language has been used to create a database/Web app framework that makes life easier without sacrificing control.

My point? I'm not sure, but I guess it's "make it easy for smart people to work naturally with the language, not fight it". Or maybe it's "don't make languages overly complex just so the computer or some CS type theorist is happy". Or maybe it's just "I hate Java generics."

Michael,

I just ordered your book on legacy code. I've recent been the recipient of 4 years of .cpp files where the original development team was obviously very confused by the concept of data hiding, so globals abound and "struct" is used in place of class so that the originators didn't have to manually use the "public" access specifier in "class" definitions.

The problem isn't that programming is too easy, rather, it is too easy to get the "right" result when coding crap. C++ doesn't enforce good programming. In fact, it happily allows "Student : public Course" as Jim Keogh perpetrated in C++ Programmer's Notebook (c) 1997. Prentice Hall. Strangely, Keogh is (at least was) a professor of CS at St. Peter's College.

I agree with the bad Java statements...but bad C++ is at epidemic proportions due to its longevity in the field.

What we have are BAD PROGRAMMERS using complex languages like C++ and EVEN WORSE programmers using easier languages like Java. There is no measure of responsibility in programming. It isn't a language problem, it is a people problem. It is further propagated by bean counters who insist that they're never more further behind schedule using the cheapest possible talent than they are when using more expensive talent. The quality of the code never factors into their bean-abacus. It is a simple, time = rate/distance problem to them. The quality of the ride from Point A to Point B are meaningless and they pay for their mistakes year after year after year. They only call "seasoned vets" when the problem grips them around the neck and holds them under water long enough for the air bubbles to stop.

Take Care.

Rob!

http://subtextual.org

Funny, some people think programming to be too easy, others think it "inhumanly hard."

I very much agree that the effort to reverse the entropy in existing systems is so ridiculously great that it's no wonder so many teams just give up, or invest in a rewrite...using different technologies but the same old lack of craftsmanship.

Rob said, "The problem isn't that programming is too easy, rather, it is too easy to get the "right" result when coding crap."

And also, " It isn't a language problem, it is a people problem.

Couldn't agree more.

Ward Cunningham once said that Smalltalk failed because it was too easy to make a mess. I don't know if this is really true; but I do know that the software productivity problems that we all suffer are greatly exacerbated by messy code. Messy code can slow a team down by significant factors; perhaps as much as 10X. If that's so, then why do we make the mess in the first place? Some of the problem might be that we hire relatively unskilled labor to write code. But another part of the problem is that deep within our souls we believe that we go faster when making messes.

A few years back I had the very unpleasant task of untagling a mass of speghetti code written in classic ASP. This had been written by a fellow developer at my company, and for the life of me, I couldn't figure out why she would have written the code in the manner she did. It was completely unformatted, no functions or subs, massive cut and paste duplication, server side mixed with client side, etc. The nature of classic ASP leads easily to this situation for many reasons. One is the technology, another that it's not too difficult to learn. The programmer that wrote this code, I realized, could make a web page work, but had ZERO thought about scalability, maintenance, or future enhancement. In short, she was a hair's width from incompetent in her job. The company I was with at the time had no problem with this type of code... mainly because no one but the developer ever looked at it. If it worked for the client, and the bill was paid, the mission was accomplished.

The problem, as I see it, is primarily a human one. Programming languages and platforms are very powerful tools. As with any powerful tool, the company and person using it are responsible for using it properly.

I work on a crap Oracle Forms app that IMHO is in the sorry shape it is because the Oracle tools (Designer, Form Builder) make it so easy for a person with 6 months of "Learn to program and get rich" training are able to produce "working" code. The app is slowly grinding to a halt as we attempt to jury rig features and apply band-aid fixes.

We a planning the move to Oracle 10G and Jdeveloper. I was hoping that this would force a re-write with a chance to do it (more) right, but that's a slim hope... The current "senior" developers are proposing writing their own Java DB framework, as they have a very negative view of Oracle and don't want to rely on the Oracle stack. Given the state of the current code base, I can't wait to see what they come up with.

I agree with everyone here that it is a people problem, and we can teach people to do better. But still, I don't think we can ignore the fact that there will still be people who screw up.

As a guy who goes around showing people how to use brooms, I think we need to put some effort into inventing vacuum cleaners. We need to take it up as a design challenge: How do we design languages/environments that make it easier to clean up programs when things go wrong? It will never be easy because so much of good design involves putting knowledge into code, but I don't think it has to be as difficult as current technology makes it.

I think that refactoring tools are just the first step. We need to go further.

I don't necessarily think that it's a problem that there are ways for people to make crappy stuff that gets the job done. If an app is 'grinding to a halt' because people are randomly throwing crap in, I think there is a management or perhaps even a money problem. People that should have access have access to the app -- a management problem. Or maybe that have that access because there's not enough money for a large enough programming staff to support their needs. Either way a recipient of code doesn't and shouldn't care how sweet the design is just that it works. Often times even if 'works' means everybody goes alot slower... well... that's still probably faster than doing whatever deed they needed by hand.

Programming is certainly not too easy, but it's often just a product that enables some real work to get done. If use a screw driver to hammer in a nail, it may take a while, but the driven nail will still hold a picture up. (Especially if it's of my fine visage.)

Zorkerman

In this context (in my opinion, anyway), programming is like painting. Anyone can put brush paint onto a canvas, and with a little skill, you can put together really nice paintings. But it takes a talented painter to make a masterpiece, regardless of the tools used.

It's more of a question that software development is spread across a very broad spectrum. Writing a bit of code that does something is pathetically easy while writing something that's comprehensible, habitable, usable, useful, etc. may be arbitrarily difficult.

Alas, most of the effort going into tools, libraries, etc. falls into two camps: trivializing and complicatifying. I.e., (trying to) convince people that using tool XYZ will make it trivial to write their code (to wit the dreams of CASE, MDA, etc.). The more grizzled approach builds on that even though the people know that the tool is just hiding all of the crap rather than making anything actually any simpler (and so it's just adding yet another layer of confusion, hence making the actual situation even more complicated). There's very little work that's really making things more simple.

Heh. I blame the tools. I know, you're not supposed to, but I do. Stupidly designed tools for stupid people are a recipe for disaster. And if you market such tools to stupid people, well...

Also, it's long been my feeling that wizards and clever IDEs are a way of compensating for crummy libraries. If you can't do the work easily enough without shoring up the development language with all kinds of cleverness (markers and generators) then the environment isn't easy enough. In fact, one might argue that programming has become so hard (in some languages & environments) that only idiots can do it and only with bizarro tools. Programmers are forced to trust the tools, because the work is too hard to internalize otherwise.

But we had cruddy code even when it was really hard. You've never seen some of the C code I saw.

But somehow I see a lot of really good Python code, and it's dead simple. Hmmm..

C++ is a powder keg. It will happily let you declare class Rock : public Bird and "fly" (or not, depending on what a Bird ISorAin't) just as far as you, the designer chooses to implement it. It gives us the power to model the real world, but it can't do the thinking for us. It is all about accepting responsibility for programming smarter code.

It is never easy to program a complex system...something to do with word origins, I'm guessing. If we take away the complexity will we lose the power? The difference between Rembrandt and my 5-th grade paint-by-numbers isn't so much a difference in tools, it is the skill of the artist. Even with the "tools" giving me an advantage by keeping my colors within the correct regions, and providing nice outlines for me to ensure I didn't cross, I don't think that anyone around would feel that anything I may have painted would show next to a Rembrandt...oh yeah, and I'm not Dutch or dead (at least not yet)!

The refactoring tools I've used won't fix really ugly code. Not even several passes with `indent' helps in some cases!

I'm not saying that C++ needs to be harder or even as hard as it is. I can't think of anything that I've learned about C++ that has been all that hard to learn...but it is not as if I invented any of it, either. One of the hardest things to teach people is "object-orientedness." It is a matter of "woah, dude...who turned on the lights..." or not. At some point, you just get it. A lot of people seem to not realize that there is even something that needs to be gotten and will fight to the "death" over their implementation choices simply because of getting the right result from their activity.

I like C++ because it is never boring, at least not to me. When people ask "how do you rate yourself on a scale of 1 -to- 10 in C++" I tell them 6.5 to 7. I've met really good OO (and often C++) people like Scott Meyers, Stan Lippman, Angelika Langer, Bob Martin, Kent Beck, Martin Fowler, PJ Plauger, Steve Duhurst, Herb Schildt, Tom Cargill and a number of others who likely don't remember me from the next bonehead to spoke to them at a conferenceand I was pleasantly amazed to find the depth of their collective knowledge overpoweringly refreshing. It is easy to be humble when in the midst of real C++ 9s and greater. Besides, all of the true wanna-bes who are conscientious of not trying to sell themselves as perfectionate bliss are already posing as 8.5s!

I learn something new and interesting about C++ every (work) day. It isn't easy because there is so much to it? Will a new and improved tool change that? Maybe, over time. I use Slickedit. It is a powerful IDE that incorporates a lot of the advances in tools into it, including refactoring, API help, parameter completion, templated document types, a power debugger interface and CMS front end and a C-like macro language with GUI editor for unparalleled infinite personalized-adjustment...not to talk about the killer visual differencing tool! But walk across the hall and three cubes down and see if you can ever get someone else to even consider looking at it because they're convinced that the world belongs to emacs or (insert your preferred editor here).

I like good tools. You know, the kind that actually do something useful for you without you having to learn a whole new programming language to get beyond the shrinkwrap? I like tools that are intuitive to use and are not solely targetting Windoze. I like tools where you don't even have to "register" to try them out...and you don't need to read 200 pages of poorly written HTML help to get the gist of why you were even downloading it in the first place.

Maybe simplicity is a good thing. Maybe the best tool is one that is self-evident, kinda like a warm pizza and a cold beer? I guess the question is whether or not we'd be happy with anything so easy after all of C++! <grin>

Here's another point of view, perhaps extending the "people problem" assertion:

Programming is very similar to building construction in many ways. Of course, humans have been building physical things for many thousands of years. We can (and do) build good building, lovely buildings, easy-to-maintain buildings, and we can (and do) build bad buildings, ugly buildings, hard-to-maintain builngs etc.

How does human society deal with the fact that it is hard to make a good building and easy to make a bad one? Through laws and holding people responsible.

I think societies would benefit from having generally more emphasis on holding software makers responsible.

We do need to be careful about that though - as Michael Loftus said above "If it worked for the client, and the bill was paid, the mission was accomplished." - what's wrong with that? Now, if the costs of dealing with the mess later was larger than the cost of avoiding the mess up front, well, that is a problem, but it is often the case that it is *not* worth it to spend the extra time and money up front to make a cleaner design - it is possible that You Are Not Gonna Need that cleaner design, for example, if the company goes out of business before it can benefit from the more maintainable infrastructure.

"Doing it better now" vs. "Doing it faster/cheaper now" is a real choice, that we all make (what kind of car/house/clothes/washing-machine/water-heater/solar-panels did you buy last year?)

It's a tough problem area.

Still, with all that in mind, I do think we should shift the social expectations towards holding software makers responsible for the quality of the software.


(I just got and started reading the Legacy code book yesterday by the way. I january I'll be working with a bunch of legacy code.)

Isn't the purpose of the language to make programming as easy as possible and the purpose of the Methodoolgy to make maintaining it as easy as possible? Isn't this the core of Agile Methodologies? In my opinion, no matter what you do or don't do with a language, people will always write bad code. It's the fault of the previous poor Methodologies that this code has been deemed acceptable in the past.