Keep It Simple, Software Guy!

Simplicity is a funny thing.  A colleague of mine was showing me an ad for Visual Studio that was set in an office.  The coders in the office had put together a ridiculously long diagram to represent the application they were building.  My colleague was disturbed at how complex this diagram was.  He commented on how we're supposed to be making things simpler with VS, but in this ad, we were condoning/endorsing making the project more complex! Interesting. Is software devleopment easy?  No, it's not.  But do devleopers make things more complex than is necessary.  I think so.  And I think it may be rooted in the masochistic tendencies of a group that is far smarter than the average and feels the need to show it.

This morning, I spent twenty minutes reading a blog of someone who spent a week at JavaOne.  I know this person in a non-business context and he seems like a pretty good guy, but rest assured, he is not a fan of the company I work for.  He managed to stick as many anti-MS comments into his posts as imaginable.  I must admit that it makes me a little sad/frustrated to read these things about a company I appreciate so much.  But that's another blog post for another day.  Anyway, apparently, he's an enterprise developer and it was interesting to see some of his comments.  Some were boiler plate (like the person who posted feedback to my last blog entry and suggested IE had holes like a “cheese grater”) comments, but others were assassinations of .NET.  I think his take on .NET Generics was that it was something for “VB monkeys” or something like that (no, that wasn't meant to be a flattering comment :>).  For those who don't know, Generics are classes & methods that work the same on values of different types. You can argue that it is a level of abstraction to help those that are struggling to accept the typing requirements of managed code by enabling some level of flexibility. Oh no!  Not flexible abstractions!   I admit that, once upon a time, I thought the level of abstraction built for for VB developers was an anathema.  Heck, I even hated Java because of what it wouldn't let me do.  “Give me pointers!“, I roared.  “Where's the challenge if you don't have to properly use malloc() and delete()“. 

But perhaps my days of “drinking the Kool-Aid“ has changed my thinking.  Or maybe it's the evolution of what's going on. Or maybe it's the fact that I am no longer counted among the smart guys and, therefore, no longer feel the need to showcase my developer machismo.  I saw an interview with Grady Booch where he said the following:  “Let me amplify something: looking backward and projecting forward on software engineering, the industry has faced complexity issues by raising the level of abstraction“. It's an industry trend and something that I'd like to think has changed software for the better.  Of course, it's a matter of perspective to believe that abstraction=simplicity.  Many see abstraction as reduced choices and potentially sub-optimal peformance.  After all, how can the performance be as good if the code underneath wasn't custom written for the task at hand.  But I still think it's a different issue and part of why all the JavaOne guys like to make fun of .NET.  The question is:  has it lowered the bar for developers? Perhaps.  But (and I suppose this is related to my last post) this snobbery has got to stop.  Now my days as a true coder are long gone, replaced by this ability to write cool little prototypes of stuff that have no business in an enterprise setting (“what's an exception?“ :>).  But I think I recognize the benefits of limiting a little flexibility for the sake of better code and it's something I applaud at the end of the day.  When I see the anti-abstractionist, I have the vision of ordering a martini and having the bartender doing the Tom Cruise “Cocktail” thing--you know, the hippy-hippy shake, flip the bottle of vermouth, do a 360 spin, drop it in the glass, pound the table, and watch the olive magically fall in the glass.  Uhhh, I just wanted a martini.  You could have saved me the 10 minute show and avoided spilling all the vodka on the floor. 

At the end of the day, a little simplicity goes a long way.  Try it.  Try it in your architectures. Try it in your code.  Don't worry--people will still think you're smart.  Heck, even the Java guy confessed that Generics were pretty cool. 

{Pearl Jam - Live at Benaroya}

Comments (4)
  1. drebin says:

    I’ve had this argument many times. There are couple of things to note, that I might pass on.

    First, yes – there is a trade-off of control for efficiency. That is almost the definition of technology – it applies to everything. You can either run down the street and have complete articulation of how your foot hits the ground or you can drive a car – and not have as much low-level control. It’s a trade-off. What’s more important to you? If you work for a business, I’m guessing efficiency. And in most shops – they take the efficient route, unless performance/control becomes and issue and we’ll write just that piece in C++ for example. You can’t have your cake and eat it too. It’s up to each developer/manager/company to decide what’s more important: efficiency and time versus performance and control.

    Secondly, I’ve come to a startling revelation that explains the Unix/Java crowd versus the Microsoft crowd. I’ve had my fair share of Unix in my sys admin days and Java (just to learn it) – but I’ve remained a MS developer – by choice. It’s plain and simple to me, because I "believe" in the technlogy and the vision of the company. And here’s the difference:

    Unix sysadmins:

    Every server is they artistic statement, their personal expression. Every server is like a snowflake, no two are the same. There is no consistency, because the sysadmin believes it’s his right to express him/herself through their management style. They also believe that since each system is virtual unmanagable by others, they have just added job security for themselves. Replace the word "Unix" with "Java" and you pretty much have the typical Java developer and java shop. No two developers are using the same tools or libraries, the code is completely inconsistent – they just orgasm at the idea of complexity and wowwing other people with their technicalness. Their code is unmanagable and no one else can touch it. They think they have job security because of it.

    So it’s safe to say, it’s no wonder why they don’t like MS tools. It’s the exact opposite of what they live every day! MS is the "man", oppressing them!

    Microsoft followers:

    Seems to me that everything Microsoft has done has been to promote re-usability, scalability and managability. A good MS-type developer will write code to the standards of the company (if everyone uses strName type variable naming, he uses that naming standard too). You should be able to pick up ANYONE’S code and pick up where they left off. These developers get excited over really simple, yet powerful code. You talk to NT/2000 systems managers and you’ll find every server set up cookie cutter. Every system is identical. They believe in consistency. Not because they want to be held down by "the man", but because it helps EVERYTHING… it makes creating programs/servers easier, you can pick up where someone else left off and it’s easily scalable.

    Now – let me tie this all up in a bow.. Now, picture you are a manager that doesn’t have a Unix/Microsoft bias. Imagine you are just dealing with these Unix sysadmins, Java duh-velopers, 2K admins and MS developers… what do you think the right choice is for the company? The answer is PAINFULLY obvious and I’ve seen it first hand a few times. Who wants to have a loose cannon Unix admin who, if he gets hit by a bus – puts the company at risk? No one!! Same goes for that ideology with programmers. Imagine the conversation of "When Joe quite, no one could find his code, then when we did – is was all messed up and not the way I normally do things"

    And that leaves one thing: job security. The unix side guys have "some" job security because they’ve scared management into not firing them. They hold them at bay with fear.

    I understand I don’t have that same hold over management. Instead, the thing that makes me valuable – is that I write good code, constistently, and I do it really quickly. That’s a MS-type developers value.

    To me, that’s the "right" way to do it. It keeps everyone in the right place, and it creates an atmosphere of "respect" instead of "fear".

    Egads. Longest post ever.. sorry – but this struck a nerve and I thought I’d share my thoughts.. 🙂

  2. Niclas Lindgren says:

    As always, all things, technologies or what have you, has its place and its uses. There is no one ring to rule them all. Sometimes you are fine with abstraction and quick development, sometimes you need effecient and to the byte code.

    You don’t want to jerk the virtual machine around in an embedded realtime application(imagine satisfying time constraints with a gc..), and you don’t want to have to write your own drivers and kernels for an office type applications.

    But one thing I have learnt along the way, part from this, is, sadly, that if things are a little more difficult, a little hard to understand, then you seem to generally attract more skilled people. If the level of abstraction rises so basically anyone can do it, they will, but they don’t have the fundamental skills still required to architecht software properly. And no level of abstraction can ever abstract that kind of knowledge requirement away I think.

    So yes, I do believe things should be simple and easy, but sadly it brings John Doe and his friends into the field, and that can potentially make things more complex in the end.

    But then again, sometimes it is fine to have John doe and his bunch to create and make applications.

    And to comment on the MS-type developing, MS has a tendency to go by the mantra, "if there is a standard, let’s make our own instead", and unix-type "if it can be made simple, let’s complicate it(and for pete’s sake don’t use a GUI!!, that will make it too easy)"

    So in the end, abstractions to make life easier are good, but never forget that it takes knowledge, education and experience to make good software in the end, even if it might seem that anyone can actually make quick progress (wait a few months and see the mess it gets into).

    Those are my thoughts.

  3. robdelacruz says:

    Good design equals simplicity though. So the act of showing off with a complicated implementation/design is more of an attitude problem rather than a technical one. Smart == Less Complexity.

    One comment, the higher the level of abstraction (.NET, Java, etc.), the lower level of control. In a sense it may come to the point where there you get the feeling that you do not control your own destiny and cannot ‘unblock’ yourself easily. Without intimate knowledge of the internals of the framework, some subtle bugs or performance gotchas may appear out of nowhere, and may be more difficult to fix.

    Now it got me thinking, could the problem be that developers who are too smart need to find an outlet for their excess bandwidth, resulting unnecessarily complex designs? Then the solution would be to put the right level of programmers on the job. For a simple business app, maybe just one or two smart people, then five average joes added for the right mix.

Comments are closed.

Skip to main content