• my wtf (unregistered)

    but thats ok, most people do. Nothing to be ashamed of, if computers aren't your thing, there is nothing wrong with staffing a convenience store shift.

  • (cs)
    author:
    Every tradesman wants to use the latest, greatest, and most powerful tools, but rarely are they appropriate for the job. Likewise, there’s hardly ever a business case to immediately upgrade all platforms/libraries/languages.

    Oh, sure. But doing so serves a more noble and valiant cause than somebody's stupid business case. It enables me to put the latest, greatest, and most powerful tools on my resume.

    Waaay back in the 90's, I was at a point where I had only Fortran and similar dead languages on my resume. Out of work for months, I finally got a small one-man-show project that was in Basic. I conned the manager into letting me do the project in C++ instead of Basic. You would criticize me for learning C++ on the job, but that single move probably resuscitated my career. I now had "object-oriented" on my resume!

    Think of all those mortgage bankers who wrote loans they knew would never be repaid in a thousand years. They knew that A: They would get their commission, and B: the loan defaulting was not their problem. I guess some of us developers aren't much different. But I submit that when I'm in the situation where a manager -- simply because corporate cut a budget somewhere -- can walk into my cube with a cardboard box and escort me out five minutes later, I owe it to myself and my family to do everything I can to protect my career. So I do it because A: I get to put <hot new skill> on my resume and B: Your system ultimately going down in flames is not my problem.

    The only reason I think programming sucks is because I never know if this is my last week or not.

    Flame on, while I go put lamb's blood over my... damn, my cube doesn't have a door.

  • (cs) in reply to EvaUnit02
    EvaUnit02:
    Still, good luck to you. I doubt we'll be working together in the future.
    I too hope we never have to work together.
  • awfwefewa (unregistered) in reply to BuschnicK
    BuschnicK:
    What a disillusioned and ranting article. Go get a refresher of Brook's beautiful "joys of the craft" article to remind yourself why you became a programmer in the first place:

    http://www.davar.net/PROGRAM/EXTRACTS/CRAFTJOY.HTM

    Also, maybe we should have a series of "the daily programming gems" instead of daily WTFs to brighten the mood a little bit.

    The article seems to make a strong statement for a conservative, keep the status quo, approach to programming. If people really followed this advice we'd still be stuck in the stone age. Sure innovation is oftentimes chaotic and change breeds anxiety - but come on, do you really believe there are two classes of programming problems: sexy ones that allow for innovation and tedious, boring ones that don't? Where would you draw the line? Do you think relational databases are the be all and end all solution to all business data storage needs? Why not fortran flat files then? They have been there before and have been working perfectly adequately for years?

    How come that innovative solutions to boring problems are usually the ones succeeding big? 37signal? Boring problem. Innovative solution.

    I have learned to find interesting problems in even the most boring domains - even without complexifying it unneccessarily to please my programmer ego. And I have worked for cutting edge, research oriented, image analysis shops as well as on coporate enterprise resource planing and customer relations management stuff. I couldn't even say where I have learned more or which of them were more interesting - although according to your narrow definition one of those is clearly sexy and the other just interface for data (isn't that the very definition of a program btw? algorithms and interfaces on data?).

    Don't learn on the job?! That must be the most WTF advice ever - try suggesting that to your boss: "Sorry, I'm not interested in learning about boring problems, I prefer to advance my knowledge at home!".

    cheers,

    Sören
    
    Yeah... Except that the "innovation" you want isn't things like "Hey, let's use Ruby!" or "Hey, let's use MVC!" or marketing things like fr-agile programming. It's huge things like CPU miniturization, massive storage for cheap, widespread usage of the internet, and connectivity everywhere.
  • js (unregistered)

    Expert system: http://en.wikipedia.org/wiki/Expert_system

    Business rules engine: http://en.wikipedia.org/wiki/Business_rules_engine

    The author's tendency to refer to business rules engines as "expert systems" makes it sound like he doesn't know what he's talking about.

  • rumpelstiltskin (unregistered)

    No engineer would ever take pride in the Rube Goldberg contraptions that run on corporate boxes. It's ironic that so many developers learn the mechanics of building such things in "Software Engineering" programs at our fine Universities. Those programs would be called "Anti-engineering Studies", if they were to be truthful. Companies need to hire real engineering majors if they want things done right. Or math majors, who can do anything well.

  • Proxima (unregistered)

    The section about programmers creating complicated (sorry "elegant") code just to keep them interested in a project reminds me of one of the best lessons I learned in Software U.

    It was in the Advanced Fortran class one evening, and our teacher, George, enters the room. His 35 students await the wisdom he has for us. Without saying anything, George turns on the overhead projector and slaps a transparency on it with a code fragment. He asked simply "what does this do?", then waited. Our young minds couldn't quite penetrate this problem, something to do with matrices is about all we could figure out. Finally, George shattered the silence and stated that that routine merely zeroed out a matrix. Nothing more. He then walked us through the code. It was elegant, and beautiful and fast! I glanced around, and noticed everyone else doing the same, smiling and nodding, all thinking "wow, that's really clever!" all hoping they could be as clever as the code's author. After a short pause, George said "I bet you think this was clever code, don't you". The young skulls full of mush nodded in unison and smiled. "You're right, it is clever....it is also bad coding." He went on to explain that while it was clever and fast and efficient, it was also bad code because we couldn't understand it! It would have taken only a few extra lines of code to do a more traditional and slightly slower approach, but it would have been much easier to support. Rare is the routine that really needs to be optimized, he said. "Choose clarity over speed, if speed is not absolutely needed."

    So whenever I find myself trying to hand polish a loop and things get more and more complicated (er, "elegant") I think of George's example many years ago and design for readability not cleverness.

  • awfwefewa (unregistered) in reply to js
    js:
    Expert system: http://en.wikipedia.org/wiki/Expert_system

    Business rules engine: http://en.wikipedia.org/wiki/Business_rules_engine

    The author's tendency to refer to business rules engines as "expert systems" makes it sound like he doesn't know what he's talking about.

    They're pretty well the same thing. Where's that thing on Wikipdia where someone gets to ask to merge articles together?

  • SomeCoder (unregistered)
    Code Dependent:
    As frustrating as it can be to work with the uninspired, sloppy developer, the contrary – the inspired-yet-misguided one – is several magnitudes worse. A few bugs and painful-to-maintain code pale in comparison to the disastrous results an improperly motivated developer can deliver.

    I'm guessing this is what happened to the project I'm currently working on. I'll be submitting this to Alex at some point but suffice it to say for now that it was a simple task that should have been done with a small script. What came out was a 19-tier architecture of death.

    The original task is definitely not sexy but doing it the simple way is far better in the long run.

  • Starbuck (unregistered)

    The real WTF is calling yourself a "rockstar" if you are some l33t c0dEr. I don't care how "sexy" your programming skillz are, that hot chick in HR isn't going to sleep with you.

  • Whole Wheat Noodles (unregistered) in reply to Code Dependent

    Oftentimes the client have you against the wall. Working at an ad agency, I've come to accept that it's just the norm. As long as I'm paid for the extra work, what does it matter that the company isn't?

  • (cs) in reply to John Coleman
    John Coleman:
    We should just suck it up? Screw that. When the job sucks and the work is boring, get a new job. You'll never catch me bowing to some lame employers need to create HTML forms, define fields, or do any other type of business-oriented garbage. That's for the entry-level slaves and ONLY for them.

    Wow! So you're too high and mighty to actually do any real work, and want to just live in your own imagination. Go for it.

    John Coleman:
    If you don't like your job, leave. If your jobs turns into that tedious crap, leave.

    If you like living on the streets, leave. If you like eating at soup kitchens, leave. If you like wearing rags, leave. If you don't like any of that, grow up. Mom won't let you live in her basement rent-free forever.

    John Coleman:
    Having said that, your seems to perfectly describe that way most people think and live. It's also why the world sucks. People need to suck it up and STOP bowing to their employer and start rioting in the streets for work that doesn't suck. I'd literally rather be homeless than doing BS "business" stuff.

    Right on, brotha! Let's stick it to the Man! Up with people! Viva la revoluction! Enjoy the streets!

    Grow up. Not all jobs are fun and games. And bills have to be paid. You're obviously still in the "juvenile child found a job" stage; just wait until you grow up and join the adults who have mortgages, families, and need to look at things like college education for their kids and retirement some day without being in poverty. When you get to that stage of maturity, you quit thinking about leaving your job so quickly when it's stable and pays well.

  • Dirge (unregistered)

    Software development is a unique profession in that we can use our skills both on the job and for our hobby.

    If you can't use your professional skills at all in your hobbies, then IMO you are probably in the wrong line of work. There are a few types of profession where it may not be practical (explosive demolition, nuclear reactor engineering, and maybe bioengineering come to mind), but in general I think it's pretty sad when someone has no outside interest in what they do professionally.

    And then there was this one guy, James Taylor, who basically called me an idiot for suggesting that developers get their hands dirty with business rules.

    No, he criticized you for "[writing] this system so that only a programmer can make changes to policy". And he was right. It's one thing to know the current business rules well enough to design a system with them in mind. It's another to build a system where code changes are required to change those rules.

    Should corporate developers design systems so flexible that software which was written for a grocery store chain still be usable without code changes if the company becomes an aerospace defence contractor? Probably not. But it shouldn't require a recompile of the cash register or payroll software if Oregon decides to switch to a sales tax, or Washington switches to an income tax.

  • Frustrated (unregistered)
    5. Tedium is Inescapable. No O/R-mapper or code-generator can ever solve the fact that records, fields, validators, etc. need to be defined, by hand, in at least two places (front- and back-end). A UI generated from the database is just as bad as the database that’s generated from the UI.

    And if you have a UI generated from the database, and a database generated from the UI, you end up with Filemaker

  • (cs) in reply to sir_flexalot
    sir_flexalot:
    Everyone strives to make the code in budget, under deadline, etc. Real rockstars can do that and create elegant code as well.

    Actually I have come across a lot of people who aren't interested in time and budget, and will go to great lengths to extend a project for no other purpose than to create a ridiculously complex system that is impossible to maintain. This is not elegant code - elegant code gets the job done in the simplest way possible... not in the most clever way possible. There is a big difference there, and I've been tasked with cleaning up the code for many project over the last 20 years, and the biggest problem I see in most of them is too much code, too complex/abstract, and a weak framework and/or database. Alex hit the nail on the head with this one... certainly one of the best articles EVAR on this site! Good job Alex!

  • Neil (unregistered)

    I like how they censor your comments here just because you say the article was boring and tedious, which, IMHO it still was.

  • Paul W. Homer (unregistered)

    Aw, now that you've given away our programming secrets, how are we supposed to hire new people to do all of the boring and tedious work for us? The whole point of a ponzi scheme is to not tell people about it ....

  • someguy (unregistered)

    Complain about how "programming sucks", or fix it, by changing what "programming" means. http://www.subtextual.org/ is a slow-moving attempt to make programming work the way programming actually works.

    "Why are you writing code when you could be programming?"

  • Thomas (unregistered)

    It is true that business software, like all software is first about meeting user needs. However, since 80% of the cost of software is in maintenance, writing maintainable code is ALSO part of the business need. Writing something clever, IF it meets the user need AND makes the code more maintainable, is well worth the trouble. Writing something that meets the business need now but is a heinous cthulu to maintain because duplicate logic is strewn all over the application is IMO not meeting the business need.

    Frankly, too many developers only think in the short term. Sometimes, yes a simple solution with some anti-patterns like duplication is the fastest, easiest and most cost effective solution. However, it is also the case that in some anti-patterns early in the project can be the death of the project later. Imagine a project where you store people's name into a single column in the database. In a simple project that does not go beyond capturing that information, that's probably fine. If the project never expanded beyond that, then the solution is quick, cheap and easy to maintain. However, if the solution expands in scope, the decision to store than information into a single column has cost the company money.

    Developers need to be able to learn how to anticipate reasonable, realistic uses of their software and design accordingly.

  • (cs) in reply to AC
    AC:
    What's with all the hard coded values in the example of what code *should*?? look like?

    if (stateCode == "AZ" || stateCode == "TX")...

    So the next new state that adds this requirement means you have to recompile & redeploy all your code rather than just updating the data in a table.

    Not a good example for the young'uns.

    It really comes down to a) how often you have to change it, and b) whether the change is consistent

    If you find that every few months another state decides to add the same financial hurdles as Texas, then, you make it configurable.

    But, if you find that every 10 years, another state adds a new weird rule that isn't quite like Texas or Arizona, then have it hard coded. You'll never make it as soft configurable as you need without making it 10 times more complex as well.

    If you have to make something like this reconfigurable without recompiling, then use a language like Lua or Ruby or Python or something to do it. There's no point writing your own 'business rules engine', when essentially all you need is a scripting language.

  • Drew (unregistered)

    So many straw men and not enough petrol to go around.

    The underlying sentiment to all of these arguments is a simple one: Pick the best tool for the job.

  • (cs) in reply to Neil
    Neil:
    I like how they censor your comments here just because you say the article was boring and tedious, which, IMHO it still was.

    I like how unregistered users always accuse people of censoring, when it's very rarely done here for any reason.

  • blindman (unregistered)

    What an incredibly boring, tedious, and unsexy WTF article that was.

  • SomeCoder (unregistered) in reply to EvaUnit02
    EvaUnit02:
    This might be one of the more ridiculous articles I've read in awhile.

    This screams of amatuer engineering where an engineer just wants to "get it done" instead of get it done well. That usually results in code that isn't future proof, isn't modular, and is hardly maintainable. Future development cycles end up being a waste due to redevelopment of existing systems.

    So you are the one that designed the garbage I'm currently working with. Adding a simple validation to this code (something like "if fieldA > MAX_VALUE { fail(); }") takes at least 2 weeks worth of work since I have to wade through all the unnecessary interfaces, create my own interface that inherits off of the correct one, and reconfigure half a dozen XML files.

    Yeah, that's FAR more efficient than just finding the place where the data is read in and writing an if statement. /sarcasm

    Sure, it's extensible. But I tend to believe that You Aren't Gonna Need It.

    Also, apparently I fail at quoting. I was going to quote Code Dependent up above, changed my mind and forgot to remove the quote sigh I need caffeine.

  • (cs) in reply to someguy

    So many people here are jumping to the opposite extremes on this article.

    I believe that Alex was trying to simply bring to light a famous quote by Albert Einstein. "Make everything as simple as possible, but not simpler."

    When given the task of creating a simple application that serves a specific purpose (for example a digital punchcard application to track employees signing in and out) we have the opposite extremes of "lets just make it one big function and store it all in memory because that's the 'simplest' solution" and "lets make a expert system that has the adaptability to cope with almost anything the user can throw at it and then we'll have the user create business rules to make the system behave how they want it"

    Anyone with a brain can see that either of these two options are mind numbingly stupid.

    The real goal of software design/engineering/programming is to build a system that is "as simple as possible, but not simpler." Start with the basic requirements, build it in such a way that it is easily maintainable, leave the door open for reasonable expansion. ie, in a punchcard ap I shouldn't waste time ensuring that if the customer wants to expand it to an entire store management and accounting system I can easily plug in a module to do that, but it's likely worth my time to consider that perhaps the customer will want to have this application export this time data to a payroll application or might want to run a couple reports off of the time data.

    It is perfectly reasonable to have major changes require non-trivial effort. It is also perfectly reasonable to not require recompiling a 20k line program simply because the customer wanted to change the name that appears at the top of their receipts.

    The difficult part of programming comes from balancing these two extremes.

  • (cs)
    Alex:
    I’m sure that many aspiring lawyers would jump at the chance for an exciting jury trial, but would just as quickly give it up if it was in his client’s best interest to settle.
    So Alex, your saying on a typical day the average lawyer would "do the right thing" and the average programmer/developer would not.

    Ouch...that just hurts. ;-)

  • Bejesus (unregistered)

    The idea that developers needlessly complicate software to make it more interesting is pretty antiquated, and in my experience not very accurate. Developers I work with day to day find their biggest motivation to be seeing real end use of their software. Elegance means simplicity to them not complexity.

    I've never experienced a problem in meeting business requirements nor in writing maintainable code. Neither is difficult. Nor is coming in to budget and timescale as long as they're agreed not mandated.

    What's difficult is coping with business users who don't understand their own needs well enough. This leads to requirements are plain wrong, ones that change rapidly and are open to many interpretations. This is the problem that adaptive development methodologies try, with varying degrees of success, to address.

    I've found that principles like YAGNI, and practises like TDD and continuous integration make it much easier to respond to changes with confidence. Couple that with regular demonstration to customers throughout a project and so encouraging them to change requirements for the better and you create an efficient feedback loop. It's not just about the process either, the collaborative way of working this encourages actually makes a big (but hard to quantify) difference to success.

    Having worked both in that way and in old style projects with giant specifications and heavyweight change governance I find an agile approach means that we can end a project with software isn't just elegant and meeting requirements and on time and on budget, but actually does what the customer needs it to do.

    That means happier developers and happier customers, and most importantly of all better bottom lines. We're not communists after all.

  • Asiago Chow (unregistered)

    What a very "sign of the times" article.

    Software takes two basic forms, Substitutional and Transformative. Substituional code replaces one actor for another...replaces an old lady and her adding machine with billing software, replaces a factory worker with industrial automation hardware and software. The results are not changed -- you still receive a bill, still buy a hammer -- but a human is no longer doing what clearly could be done by a machine. Transformative code, on the other hand, redefines the problem to extend human ability. Audio processing software can manipulate sounds in ways that no combination of humans without such software can possibly emulate, real-time optical correction software can compensate for atmospheric refraction of light to improve a telescope image in ways no unaided humans can, the list goes on.

    This article seems to be nothing more than an incomplete exploration of the ethics of substitutive software development. It posits that boring software is good, though it doesn't really explore why, and says that you code monkeys should be happy to do good, because. The only thing really wrong is the author's belief that he is talking about Information Systems programming when in fact his concepts apply to all substitutive programming (including factory automation, not normally considered IS) and do not apply to transformative programming (including some types of communications and analysis software which definitely is IS).

    Substitutive code is good because it replaces something of very high value (human life) with something of low value (whatever it takes to run the code). The humans thus freed from their automatable toils can go on to do uniquely human things...art, music, new code, what have you.

    Boring substitutive code is good because it is more likely to succeed in it's primary purpose. If there are six people doing a job today, and you write a 100% reliable program that automates everything they have done and can move on to something else, you have substituted software (representing a finite number hours from your life) for the continuous waste of six humans for the life of the enterprise. That's a tremendous net gain. If it takes a full time maintenance programmer to keep the substitute running you've only subsituted five...still worthwhile but not nearly so good. If the software takes ten people to keep it running you have failed at your mission...you've replaced six with ten for a net loss to humanity.

    You can view this as a spectrum representing the relative good or harm of a particular bit of substitutive code. If it completely replaced 1,000,000 workers at a cost of 2 maintainers it is very good... if it replaced 50,000 workers at a cost of 14,000,000 maintainers it would be very bad. The assumption is always that the computer, having no real potential beyond doing what it is commanded, is always better for repetative tasks than the human, which does have real potential.

    So, from the point of view of substitutive code, the article has merit. It is pussyfooting around what needs to be said, though: The best substitutive code replaces not only the workers currently doing what the code will do, but the developer writing the code. To the extent you seek job security you ensure failure.

    Transformative software, on the other hand, is good when it creates a new ability that didn't exist before. The measure of how good is much harder to measure because it isn't a strict numerical "how many hours are wasted" question but one of quality, "Is my life better because I can do ______?" That can be subjective and the only real test is a market test...if you offer it, do people adopt it and consider themselves better off? In other words, Transformative good is almost exactly the opposite of Substitutive good. The fact that a World of Warcraft, Twitter, and name your particular transformative technology, needs tens or hundreds of maintenance programmers, are full of bugs, and perhaps utilize "non-boring" coding practices, and in fact results in humans doing MORE than they did before, is a indication of success. The most objective measure of their goodness is the extent to which they extend human ability. The ability to communicate instantly across the world, or to explore parts of the universe we can't reach or perceive with our inborn senses, or to simply play an online game with someone across the country, extends humanity. The measure of good is not reliability or preditcability, and it isn't how many people are needed to maintain the new ability, it's the resultant expansion of human potential.

    Successful transformative technologies naturally create opportunities for substitutive software. The very first computer chat system could be high maintenance because it transformed the abilities of its users...but once chat became omnipresent it was time for the substituters to come in and make it boring and low maintenance... why? So the transformative developers who created it aren't stuck doing what a machine can do.

    Anyway... to me the article sort of missed the mark without actually being wrong for its intended audience.

  • (cs)

    ha ha, I program video games for a living

  • (cs)

    The reference to lossless compression is pretty ironic since we just witnessed the same argument take place in "Coder Challenge" on our own TDWTF forums:

    http://forums.thedailywtf.com/forums/t/10491.aspx

  • (cs) in reply to David Brady
    I have written business rule databases, math engines, double-entry bookkeeping systems, GUI frontends to scientific equipment, and the only thing that they all had in common was that I had a great time doing it.

    Blimey.

  • (cs)

    One of the reasons that my company went to the wall, and the owner had to start another with just me & him in it, was that the replacement Windows system for our old DOS app (which was really good, a big money spinner) took bleedin' years to write. This was because the other guys ( more senior devs than me, paid a fortune) spent ages fucking around with "clever" user-configurable shit, without realising that most of the users that would ACTUALLY use it could barely log in, let alone configure anything. So now we do all the config AND maintain all the "clever" shit, which is more buggy than the rest of the 100-project app put together. That is all

  • Bobblehead Troll (unregistered) in reply to jasmine2501
    jasmine2501:
    sir_flexalot:
    Everyone strives to make the code in budget, under deadline, etc. Real rockstars can do that and create elegant code as well.

    Actually I have come across a lot of people who aren't interested in time and budget, and will go to great lengths to extend a project for no other purpose than to create a ridiculously complex system that is impossible to maintain. This is not elegant code - elegant code gets the job done in the simplest way possible... not in the most clever way possible. There is a big difference there, and I've been tasked with cleaning up the code for many project over the last 20 years, and the biggest problem I see in most of them is too much code, too complex/abstract, and a weak framework and/or database. Alex hit the nail on the head with this one... certainly one of the best articles EVAR on this site! Good job Alex!

    Two words: job security.

    It is people who are bored, underqualified, married with children, mortgaged, and want to ensure that they cannot be fired who write that kind of stuff. It may not be intentional in the beginning but it will not take long for them to notice the beneficial side-effect, which is about the same time they get their first lead position.

    They are not rockstars. They are losers.

  • Da' Man (unregistered) in reply to David Brady
    David Brady:
    If you're not having fun, you're doing it wrong.
    I agree. Those who are not enjoying this, should probably consider another career.

    Nurses are wanted, I hear. Gives a different kind of satisfaction.

  • (cs) in reply to Starbuck
    Starbuck:
    The real WTF is calling yourself a "rockstar" if you are some l33t c0dEr. I don't care how "sexy" your programming skillz are, that hot chick in HR isn't going to sleep with you.

    Agreed. I hate the term "rock star" programmer. If such a thing exists, I've never met him (or her).

    Alex:
    5. Tedium is Inescapable. No O/R-mapper or code-generator can ever solve the fact that records, fields, validators, etc. need to be defined, by hand, in at least two places (front- and back-end). A UI generated from the database is just as bad as the database that’s generated from the UI.

    Have to disagree here. Why can't an ORM do what it is supposed to do... generate the object model and the relational model, plus the basic glue code that holds them together?

    I'm not being sarcastic... I've started to dig into Doctrine and don't have a lot of experience with it yet... but it seems to me to solve exactly the problem which you are referring to.

    The big problem to me still seems to be that there is no universal business code library which can provide a lot of commonly needed logic off-the-shelf. I was thinking about this the other day as I wrote my 1-millionth "US Phone Number Validator". Why am I even using a framework which doesn't have a shitload of common validations built-in?

  • Da' Man (unregistered) in reply to Bobblehead Troll
    Bobblehead Troll:
    It is people who are bored, underqualified, married with children, mortgaged, and want to ensure that they cannot be fired who write that kind of stuff.
    Now excuse me for saying this, but does anybody here have the impression it might be even just a little bit difficult finding a new job, if you just *claim* to know your stuff?
  • (cs)

    Good article by Alex and really good comment by Mr. Chow.

  • (cs)

    Technologies can reduce drudgery - take data binding in .NET, for example.

    And while I agree that you don't want to reinvent VBA, tools such as rules engines, workflow, DSLs, and BPMs can move the (ever-changing) business logic out of your applications and into areas where domain experts can edit it.

  • awfwefewa (unregistered) in reply to savar
    savar:
    Have to disagree here. Why can't an ORM do what it is supposed to do... generate the object model and the relational model, plus the basic glue code that holds them together?

    I'm not being sarcastic... I've started to dig into Doctrine and don't have a lot of experience with it yet... but it seems to me to solve exactly the problem which you are referring to.

    ORMs only solve pretty basic database problems. Once you get past a certain, and fairly common, level of complexity, they're pretty useless, or they require just as much thinking as if you wrote the SQL yourself. So what happens is that you have a bunch of code using the ORM, and a bunch of other code that does all the value-added stuff, and guess which one actually lets you bill more than $10/hr?

    Of all your programming skills, SQL is probably the one that you'll still be using even if you've moved on in everything else, what with data being the most important permanent artifact systems generate.

  • Boyd (unregistered)

    I like what you say, I actually wrote a software developer monitoring framework which verify that your employees focus on fulfilling their obligation. It comes with a visual rule based enterprise designer where you can connect template of productivity issue such as "over-architecturing" or "spaghetti code" to an incentive/blame delivery framework INCDEF(tm) which can automatically reward or punish developer by adding or substracting an instance of monetary value from their paycheck. Of course other incentive blame could be implemented by plugins.. contact me if you are interested...

  • (cs) in reply to YAYitsAndrew
    YAYitsAndrew:
    ha ha, I program video games for a living
    ROFL, that's not what it used to be. Maybe you could explain what's so cool about being an anonymous face in a huge team working on a soulless corporate product that gets shitcanned half-way through? And never getting any royalties even if you do make it into production?

    Games dev hasn't been exciting since the early 90s.

  • -mika- (unregistered)
    3. Learn Off The Job. Self-improvement is a tenet of every profession, but the place to do that is “off the job,” i.e. not while developing information systems. Instead, learn by creating applications for yourself, your team, or perhaps even some open source project.
    Unfortunately, business software devs don't have much "off the job" luxury. In the worst case, early mornings, late nights and weekends go to meed deadlines on actual development, while workdays are full of unexpected calls. Many of us intended to be a developer, but instead became a trusted consultant doing boring but "urgent" stuff that internal staff does not want to learn.
  • imalc (unregistered)

    Code should be as simple as possible, but not simpler. I think that summarises the article as simply as possible.

  • Was Programmer (unregistered)

    This is by far the most brilliant article on this site! An excellent summary of issues that not only the developers, but also their managers (who in our case were once programmers) struggle with every day. The grass is not greener on the other side, but still people keep on complaining about the boring nature of the majority of our projects.

    Find your satisfaction from getting things done instead of intellectually stimulating challenges, and you'll be ok. Keep on trying to find the "ultimate software company" and you'll either die in the competition or search forever. In the end, we all work for the client.

  • anonymous_coder() (unregistered)

    Wow, did this article stir up a hornet's nest. A whole lot of people got really pissed about being told their job should be boring.

    Guess what?

    It should.

    I hate working after "clever" people. They aren't as smart as they think they are, and leave a huge mess because they're too awesome to clean up after themselves. They insist on using the flavor-of-the-week technology, indulge in rampant fanboyism and platform bigotry, and generally behave like a seven year old boy. A spoiled one.

    Business programming is a craft, not science. If you think you are going to be doing innovative code when writing an accounting or billing system, think again. It must be simple to understand, auditable, and maintainable. It must be done in a technology that is common enough that you can hire an entirely new development team in a hurry if there's a plane crash or something.

    It also must work. All the time. And that means pedantic error checking, and lots of it.

    So all you m4d sk33lz coders out there who think that Alex is full of BS for saying coding should be boring, good luck with that whole "job" thing. Because I wouldn't hire you - we don't need to induce "excitement" in our customers' lives.

  • (cs) in reply to Asiago Chow
    Asiago Chow:
    Software takes two basic forms, Substitutional and Transformative. Substituional code replaces one actor for another... Transformative code, on the other hand, redefines the problem to extend human ability...

    Great comment; I think we're on the same page, though with different terms. Your Substitutional to my "boring", and Transformative to "sexy".

    Transformative software has done nothing short of completely change the world that we live in. But at the end of the day, we still need to continually (but gradually) improve our business processes, and Substitutional software is the only way that can happen.

  • mh (unregistered)

    I think the point is that the part of your code that's boring to write SHOULD be boring to write. Last thing you want is for a database layer (for example) to become exciting - then you got trouble. Even worse, if you try to make it exciting yourself you got real trouble.

  • Jon (unregistered)

    I agree with the gist of the article, but I think the examples are bad. Those rules clearly contain external parameters (eg states which require certain attachments) which shouldn't require a code change. Think of the recent UK Vat change - I know a number of coders who would have hard-coded Vat at 17.5% thinking "it will never change" - and they'd have a problem when it changed to 15% quite suddenly.

    That doesn't mean you use configuration files or a thousand layers of abstraction. You hard code the rules, but you have to think carefully about how to parameterise them. You hard code the rule that certain states always require certain attachments, but which states require which attachments become configurable - not using XML, but through the same carefully controlled interface as everything else.

    Someone with enough knowledge of the business should by definition be able to understand an appropriately parameterised and presented rule. Any business owner would have had no issue understanding what the "VAT Rate" setting did, and would be quite grateful for it. In the same way, I'm sure a "Compulsory attachments" interface would be pretty self-explanitory.

  • (cs)

    What are the boring bits of programming?

    1. Repeatedly typing in line after line after tedious line of similar code.
    2. Picking the same type of bug out of many different parts of a bloated codebase.
    3. Manually deploying version after version, and redoing it when you miss a step.

    The solution to boredom is to make a better codebase... one with fewer lines needed to express a given thing, fewer places for bugs to hide out, and automated deployment.

    It'll make your job less boring and make your coworkers' jobs less frustrating and the customer's job less frustrating to boot.

    Combating boredom by overengineering and learning a whole new language on their dime leads to more frustration for you and everyone else, and ultimately more boredom for you as you struggle to keep your beast from falling apart.

  • (cs)

    Another good way to combat boredom is to create a codebase that anyone else can take over, so you can be assigned to a whole new project instead of spending years and years maintaining a beast that only you understand and that you have gotten sick of.

    "Job security" is another word for stagnation. Write the kind of code that people want to have in their codebases, and you'll get to put your fingers in all sorts of projects.

Leave a comment on “Programming Sucks! Or At Least, It Ought To ”

Log In or post as a guest

Replying to comment #244445:

« Return to Article