Programming Sucks! Or At Least, It Ought To

« Return to Article
  • Richard 2009-02-17 09:20
    This is not the type of software that changes the world. In fact, it probably won’t even put a smile on someone’s face. Its sole purpose is to add to the bottom line by making other workers be more productive.
    Actually, I'd argue that it is exactly this kind of software that changes the world. By taking care of the mind-numbing tedious tasks that used to employ scores of people at most "real companies," we enable the business evolution without which business revolution wouldn't be feasible. But maybe I've been living in the enterprise world for too long.

    Agree with the main thrust, though. Don't try to write the cleverest program. Solve the cleverest business problem instead, using your mad design and development skillz. Its actually harder that way, and far more useful, not to mention visible to those both in and out of your department.

    Captha: iusto.
  • Mike D. 2009-02-17 09:21
    I am interested in these 8.5" disks of which you speak. The ones I saw a couple decades ago on a particle analyzer for an electron microscope were 8.0".

    Ed: Whoops, fixed!
  • sir_flexalot 2009-02-17 09:23
    Everyone strives to make the code in budget, under deadline, etc. Real rockstars can do that and create elegant code as well.
  • kastein 2009-02-17 09:27
    I'm lucky... I get to develop kernel/firmware code for internal use only... in C and assembly, my favorite languages.

    What's with all the idiots rushing to be "first" and posting captchas still? Wasn't that last 'cool' sometime last century?
  • Zaratustra 2009-02-17 09:30
    I agree that coding should reflect the user's needs, but often compiling and deploying software is a pain because of regulations and red tape.

    What I like doing when able to is to have the 'hard' code (the side that isn't likely to change and requires speed and libraries and all that) in C++ and the 'soft' code (bound unto the human world of measures and numbers) in a script language such as Ruby. Ruby is immensely more pliable when it comes to doing data structures properly.
  • Code Dependent 2009-02-17 09:45
    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.
    Gawd, how true, how true! It is part of my responsibility to maintain and occasionally add new features to a sprawling mess of interrelated projects created several years ago by a contractor who evidently felt the need to demonstrate his programming prowess. The solution consists of nine projects. Four separate but interdependent websites; three separate business layer projects; a separate project specifically for homebrew webControls; and a project strictly for interfaces. The interdependencies are so complicated that I had to make a chart of the order of compilation so that each project in turn could be published to buildOutput to be linked by those referencing it.

    Having worked with it for about four years now, I'm aware that the solution could have been designed just as effectively without all the grandstanding; but it's functional, so we keep it.
  • Gareth Adams 2009-02-17 09:46
    If writing boilerplate code is too grating a task for you, then your framework isn't making things easy enough for you...
  • Rev. Creflo Baller 2009-02-17 09:47
    For so long our "profession" has rewarded people who have great coding skills but no skills for requirements gathering, business process design, project management, etc. Because so many of us have poor "soft skills" but are still regarded as acceptable developers by our peers--who else has the capacity to judge?--the business people have increasingly come to think of us as interchangeable laborers. Once you demonstrate that you're no better at requirements gathering and just as good at writing 1000 lines of code as some toothless guy who was herding goats 200 miles west of Xian last summer, guess who's going to get hired to do the 1000 lines of code?
  • Merijn 2009-02-17 09:47
    The point is, elegant code does not equal to "newest buzzword framework", "grooviest language" or even "uses XML".
    Elegant code can be, say, java 1.4.2, business driven etc.

    Yes, I switched jobs to be able to work on a university for a "nutty professor". Now I have to *think* what, how and why every hour, rather than once a month, an that is my current challenge.
    Some of the applications I develop are 20+ years old, and I am happy that many of my predecessors were not of the "let's invent the square wheel-with-complicators" type.
  • Cj 2009-02-17 09:50
    I really enjoyed this article.

    I will try to get my co-workers to read this.
    Some of them just cant seem to "do just what's needed" and the result is more than often overly complex code thats time consuming to maintain.

    I always say: pick your battles! Sometimes theres room (time+money) for those truly beautiful solutions and other times just do what was asked for, and move on to the next problem.

  • John Coleman 2009-02-17 09:52
    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.

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

    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.
  • Anonymous 2009-02-17 09:58
    No, screw you.

    Enjoy being business-r4ped everyday and convincing yourself it's the right thing. You probably don't have another option anyway.
  • Steenbergh 2009-02-17 10:02
    BS "Business" stuff?? Man, you have a job BECAUSE of that business, and its needs for improving their core "business" processes! So don't be all amazed when you need to make code every once in a while that doesn't generate a user input form based on XML composed by your clients, but actually checks if LedgerAmt<=50000...
  • Alan 2009-02-17 10:03
    I used to do business software (stock-control systems) - and i used to do all sorts of over-engineered stuff.

    Now i work on desktop widget software - much happier.
  • Someguy 2009-02-17 10:03
    So...I think I'm going to go throw myself into oncoming traffic now. Thanks for the pep talk.
  • Dan 2009-02-17 10:04
    "Software development is a unique profession in that we can use our skills both on the job and for our hobby"
    Utter crap. Mechanics? Carpenters? There are plenty of skillsets that can be used professionally and for personal enjoyment.
  • Squiggle 2009-02-17 10:10
    I have to fully agree with the sentiment of this article.

    It should be noted that almost all the demotivating factors throughout my professional existence stem from either the business (bad management) or the code base (complex, clever or otherwise unmaintainable code).

    "Boring code" is the best code I've ever worked with, and 80% of my time is spent maintaining other people's work.

    I'd like to note that most of you will probably code in your spare time, and it's at home that you'll have free reign to write as much clever code as you want.
  • Grew 2009-02-17 10:12
    Dan:
    "Software development is a unique profession in that we can use our skills both on the job and for our hobby"
    Utter crap. Mechanics? Carpenters? There are plenty of skillsets that can be used professionally and for personal enjoyment.


    Porn star.
  • Leo 2009-02-17 10:12
    As Michael A. Jackson said in his 1975 Principals of Program Design, "Programmers… often take refuge in an understandable, but disastrous, inclination towards complexity and ingenuity in their work. Forbidden to design anything larger than a program, they respond by making that program intricate enough to challenge their professional skill."


    Indeed. And as Michael J. Jackson said in his 1983 Thriller, "Billie Jean is not my lover."

    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.


    Well, he has seen fire, and I believe he's seen rain as well. Also sunny days that he thought would never end.
  • EvaUnit02 2009-02-17 10:12
    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.

    Using antiquated technology is...absurd. It means you're coding around deficiencies that have been solved in later iterations of the technology. If there has ever been a better way to code yourself into a corner, I haven't seen it.

    Learning off the job is all well and good. Learning on the job is better. You're enhancing your skills and your employer directly benefits from that. Better employers recognize this and not only encourage continued learning, but require it (on the clock).

    Tedium is not only escapable, it's your job to escape it. You shouldn't be reinventing the wheel and you should not have institutional redundancies. To pick on your example, a UI is one of the easier things to dynamically generate. Moreover, your UI shouldn't have prior knowledge of your model to begin with. The two should be seperate entities.

    Still, good luck to you. I doubt we'll be working together in the future.
  • Squiggle 2009-02-17 10:12
    I have to fully agree with the sentiment of this article.

    It should be noted that almost all the demotivating factors throughout my professional existence stem from either the business (bad management) or the code base (complex, clever or otherwise unmaintainable code).

    "Boring code" is the best code I've ever worked with, and 80% of my time is spent maintaining other people's work.

    I'd like to note that most of you will probably code in your spare time, and it's at home that you'll have free reign to write as much clever code as you want.
  • AC 2009-02-17 10:21
    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.

  • DaveK 2009-02-17 10:21
    Got as far as the bit about "boring" programming, and agree completely: boring programming is boring. So I stopped reading.
  • anon 2009-02-17 10:29
    sir_flexalot:
    Real rockstars can do that and create elegant code as well.


    Of course every one thinks they are a bloody rockstar but they aren't. That is why I keep a LART handy to beat the rockstar out of those who think they are.
  • Bugs... 2009-02-17 10:29
    Debugging's where it's at. Nothing beats the buzz of finally finding what caused that damn problem at long last!
  • WayneCollins 2009-02-17 10:31
    Over the years, I've dealt with boredom in several ways, some helpful and some... not so much.

    The best way I've ever come up with is to invent ways to make everyone's development process less painful and tedious. Custom debugging tools, build processes, and so on.
  • Charles400 2009-02-17 10:32
    Author:
    Programming is not fun. It’s boring, it’s tedious, and it’s certainly not challenging. And no matter how much you stretch it, programming is most definitely not sexy.


    We come to this site to escape the boring and the tedious. What do you give us today? Boring tedium. Jeez!
  • GooberMcNutly 2009-02-17 10:38
    If programming weren't boring, who would go to all the trouble to make really cool Easter Eggs?
  • Max 2009-02-17 10:41
    Don't write articles like this. You've just told us that:

    1) You don't have any experience in modern, agile development.
    2) You aren't a rockstar, because it doesn't even take a rockstar to both meet business requirements and write elegant code.
    3) You write bad code -- if you didn't spend most of your time fixing old code, you would write a clean system, then have time to go back later and build an "expert system."
    4) You don't have experience writing metadata-driven apps. If you did, you wouldn't lump all fancy-schmancy systems together under the term "expert system".
    5) You have never really changed your business with your work -- those of us grounded in reality know that simple effective code can change the business profoundly.
    6) You don't practice what you preach - if you really learned the business and served it, you would love to write "boring" code. I am thrilled beyond belief when I can write some stupid little piece of boring code that also happens to revolutionize some business process.

    In short, this whole article is a WTF.
  • BuschnicK 2009-02-17 10:43
    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
  • drf 2009-02-17 10:45
    EvaUnit02:
    This might be one of the more ridiculous articles I've read in awhile. [...]


    I was going to say something to this effect, but EvaUnit02 said it much more eloquently than I could.

    Look, one doesn't design and write modular code for our own recreation. Writing spaghetti code (for which "soft coding" is a euphemism) may be acceptable for small projects, but the value added by reduced development costs simply cannot be justified considering the added maintenance and testing costs, and the propensity for bugs to emerge that incur substantial costs on end users. Well-designed, modular code (which you deride as "all sorts of design patterns, interfaces, supplementers, and a whole lot of classes") is for all but the smallest projects in the business interest of the client, and not for the personal satisfaction of the developer.

    Well-designed code requires a higher upfront cost at the design stage because factors like modularity, security, extensibility, and scalability are embedded into the final solution. The costs are recouped in more secure, more robust software that is more cost-effective to maintain, expand, and suit the business needs of the enterprise.

    Alex, you write that "The true rockstars can deliver software before deadlines, under budget, and that does exactly what the business needs." With all due respect, this is nonsense. Applications have lifetimes that far outlast the development lifespan, and we have seen countless examples on these pages of undocumented, uncommented, unmaintainable spaghetti code that is easier (and would make more business sense) to replace entirely than maintain. You are calling the writer of such awful code a "rockstar", the penultimate programmer. I profoundly disagree.
  • kastein 2009-02-17 10:47
    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.

    Except this is financial nonsense code, so it is highly unlikely that another state is going to have exactly the same stupid form... more likely they are going to come up with their own version of it, so you'll now need to add another BusinessRuleHandler, another table (which will have one row), another BusinessRuleExceptionHandlerFactory... oh, and that table you want to update? You now get to update it on every DB server at every corporate office and/or company licensing the software.

    I'll take adding two more lines of source, recompiling, and rereleasing, thanks. Read the article that code was quoted from, you seem to have missed the point entirely.
  • galgorah 2009-02-17 10:54
    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.

    I believe Alex was just using the examples to illustrate his point. I don't think he was saying that this was the best way to do it.
  • Postie 2009-02-17 10:54
    I must confess I agree with the article. Doing only what is needed is the only efficient and productive method of working. Plug-ins and offering the 'just in case we need it in the future' option rarely pay off and just cuase more problems.

    I feel lucky that during my day job I help with the large-scale bespoke framework the company insists on developing, whilst out of work I help my dad with embedded systems, with tight limits on hardware that any of this 'trying to progress for the sake of it' doesn't go on - not a lot to do with 128 bytes of RAM. Work pays the bills, out of work challenges me.
  • silent d 2009-02-17 10:59
    I think Dickens said it best when he wrote "IT was the best of times, IT was the worst of times."
  • Sucks 2009-02-17 10:59
    This article sucks.

    Good job. You've highlighted the problem and then said "Suck it up and act like the tool you are."

    Way to think inside the box, Alex.
  • bigtuna 2009-02-17 11:00
    kind of agree with the article... but this really applies only to small-ish applications with limited scope. the more users, the more code, the more scope... the more you NEED people who use all those crazy interfaces. that kind of thing makes life easier down the road. :)

    for the basic internal app, you're spot on, and I've seen dozens that were over-thought and ended up being a PITA to maintain because of it.

    loving the comments from the folks on here, too... quite a disparity between the programmers I'd never want to work with and the programmers who agree with the article...
  • Matt 2009-02-17 11:00
    EvaUnit02:

    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.

    Using antiquated technology is...absurd. It means you're coding around deficiencies that have been solved in later iterations of the technology. If there has ever been a better way to code yourself into a corner, I haven't seen it.


    Actually, I'd say this screams of someone who's had to work in a business environment where lovely shiny happy code isn't the top level driver, but the business is instead. If you're working in a company where a problem's causing problems for the sales force leading to lost opportunities, poor forecasting leading to factory component overstock or the like, do you go for the simpler established solution that you can get working in a couple of days, or do you go for the more elegant solution that will take a couple of months? Because if you chose option 'b', it is highly unlikely that you'd be working in the same company as anyone who chose 'a', because you'd have been shuffled out the door very quickly. The company's losing money while you fanny about getting the nuances of the new technology you've fallen in love with sorted. Getting it done well enough is almost always more important than getting it done perfectly.

    Using the obligatory car analogy, you're talking about trying to develop something like hybrid electric/biofuel as next year's model at a manufacturer that builds petrol driven cars. It might be more fuel efficient, it might be a wonderfully interesting thing to implement, it might lower costs over time, it might be something for the R&D department, but as it's needed for next year it's not going to be ready in time.
  • Uncle Bob Martin 2009-02-17 11:04
    I agree with everything here except that any of it sucks. It is a joy to write clean and well structured software that solves mundane problems. That joy comes from the satisfaction intrinsic in doing a good job. Being professional doesn't suck at all. Being professional is the most fun of all.


    Note From Alex: I definitely agree, and hope this setiment came out in the article. I love doing what I do, not because of the "boring" tidbits of code required to do the job, but because of the overall value I can deliver.
  • Adriano 2009-02-17 11:07
    Alex, it should be _Principles_ of Program Design. Cheers.
  • Odi 2009-02-17 11:10
    That's exactly his point. You (YOU) don't know the project. You don't know the business. Is there actually any need to have these values configurable? Is there anyone who will (be able to) maintain that configuration? Is there a business process that drives that maintenance? If not then the users will probably ring the manufacturer anyway to have something changed here. Is is difficult to deploy a new version? Maybe its not. Maybe its interpreted code like PHP even, so no recompilation necessary, no downtime even involved. Probably the stateCode values never change, but new ones are added. So you will have to add logic here anyway and configuration doesn't solve that problem.

    This code is simple. Anyone can understand and maintain it. Even a guy that's new on the project. There is no need to make it more complex. Changing it without knowing the business is like premature optimization without profiling.
  • Code Dependent 2009-02-17 11:14
    Uncle Bob Martin:
    I agree with everything here except that any of it sucks. It is a joy to write clean and well structured software that solves mundane problems. That joy comes from the satisfaction intrinsic in doing a good job. Being professional doesn't suck at all. Being professional is the most fun of all.
    I used to buy those Logic Problems magazines and work them for fun. Then I got a computer and discovered programming. The principle is the same: you give me a problem, and I find a solution. Only now they're paying me the medium-sized bucks to do what I used to do for fun and no bucks.

    It's still fun. I love what I do for a living.
  • Anonymouse 2009-02-17 11:15
    Yea, that's it. I think I'm going to be unsubscribing.

    This article is supposed to be what, exactly? Enlightening?

    Writing straightforward code instead of clever code sounds great, but when you have a million lines of copy-and-pasted HTML with scattered bits of PHP to generate each page individually, you really have to ask yourself if you would have been better off spending some time on proper design.

    Whenever you can make the codebase smaller without sacrificing features, it's usually a design win. And it's the exact opposite of what you're preaching. Sure, you need to define your database fields, and then define the name, label, and limits of the field for the frontend, but your framework should do all the rest: generating client-side validation, performing server-side validation, generating error pages, pulling and pushing data to and from the database. And you should have the ability to template in any common UI elements.

    And it doesn't even take a very "clever" framework to do all that. Once you have that framework, adding a new type of report generation involves one new database table and about 20 lines of clean, simple code with very little that can go wrong.

    Why not spend some of that effort on detailing good, robust design processes, good factoring, and the like, instead of just ranting that you should hate your job. The more your code paths converge, the fewer places bugs can hide.

    Avoiding bosses who believe as you do is why I changed careers. Hardware is much less forgiving of "just do it" attitudes and poor engineering rigor.
  • Anonymous 2009-02-17 11:17
    As far as I'm concerned there is absolutely no defending the "inspired-yet-misguided" coder and I would agree that they are vastly more of a problem than the inexperienced or sloppy coder. Even referring to them as inspired-yet-misguided is way too generous since these are the people whose architectural behemoths of mistakes take weeks or months to unpick (and sometimes never get unpicked at all).

    I don't consider a coder to be inspired or even proficient if they let their personal desires drive their coding decisions. It doesn't matter how much raw skill you have, if you don't have the discipline to apply it correctly then you are not a good coder. Interestingly, you will very often spot other major failings with this type of coder. For example, I find they will often push ahead with new code at the cost of maturing their existing code. Instead of adding decent comments to the class they just wrote they're pushing on and writing the next one. If the drive for new code comes at the expense of maintaining the existing code then you've got another problem on your hands.

    As a general rule I consider these coders to be lost causes and spent my tutoring time on the juniors, who stand a very real chance of being vastly superior.
  • D.K. 2009-02-17 11:18
    I wish the business would now what they want all the time. It becomes really annoying, when you deliver the app as per spec, they play with it and decide to change the requirements, you have to throw away half of the code and cannot charge money for these changes, because in "economical crisis" you won't get more money anyway.
  • lanmind 2009-02-17 11:21
    I certainly don't agree with the whole article - for instance, learning should be integrated with the job, not set apart from it - but some good points are made. There are tons of devs out there who aren't nearly as brilliant as they think they are, but still attempt to write clever code - code that makes the rest of us want to throw ourselves under trucks.

    I think it's pretty safe to say that that the truth is somewhere in the middle. Real rockstars know when to build the wizbang 9000 and when to KISS. In my humble opinion, it boils down to how easy it is to maintain the final product.
  • galgorah 2009-02-17 11:22
    While I do agree with the spirit of your article Alex, I think decisions like this need to be decided on a case by case basis.

    Case 1 (Training management app):
    This web app was developed to Allow employees to sign up for trainings (Mandatory and optional) as well as request them. It hooks into Active Directory and exchange server. It allows individual users to track what courses they have taken, What ones are offered, etc. HR can also see who has taken what, etc. There are other features, reporting, outlook integration, etc. When we developed this app we knew that it was going to stay more or less the same for a long time without any changes. Such has been the case. I've had to fix 3 bugs in 2 years. We made the decision not to make this system overly complicated with creative code. took us about 2 months to make once specs were finalized.

    Case 2 (A very high profile app in the healthcare industry in massachusetts):
    This application we knew needed to encompass a pda version as well as a web app accessible to healthcare providers via vpn. Sql server CE on the pda's and Enterprise on our end. This app would include forms that would change with both state and federal regulations via tweaks to the project it was the backbone for. Basically the application has to change and evolve with the project. This being the case we decided that it would be better to make it more "enterprisey" as we would constantly be modifying it to meet the state's (our only client) needs. Again it has worked out extremely well and helped mitigate serious issues in the healthcare industry in massachusetts. If you want links to info on the project pm me and I will send them.
  • MrsPost 2009-02-17 11:25
    Uncle Bob Martin:
    I agree with everything here except that any of it sucks. It is a joy to write clean and well structured software that solves mundane problems. That joy comes from the satisfaction intrinsic in doing a good job. Being professional doesn't suck at all. Being professional is the most fun of all.

    You sir are my hero today.

    I write boring code. I write code that meets the business requirements and is as simple as possible. I also use descriptive variable names, normalized tables and all the other things that could be done 'creatively'. I also try to make my code comments as relevant and useful as possible.

    Why do I do this? Because that's the way I would want to see the code if I were doing maintenance. And because that's what is needed.
  • David Brady 2009-02-17 11:26
    If writing software is boring, the problem is not the software. 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.

    Maybe it's just me, but writing software is about solving problems, and I find that interesting and fun regardless of the application. "Sexy" is in the eye of the beholder. At the end of the day Google Maps is just another map application, the iPhone is just another mobile device, and anything written in Visual Basic is--well, okay, that one's probably not ever sexy.

    If you're not having fun, you're doing it wrong.
  • Code Dependent 2009-02-17 11:27
    D.K.:
    I wish the business would now what they want all the time. It becomes really annoying, when you deliver the app as per spec, they play with it and decide to change the requirements, you have to throw away half of the code and cannot charge money for these changes, because in "economical crisis" you won't get more money anyway.
    Something is seriously wrong with your business processes if you get specs, deliver to them, and then have the client change them without paying you for the extra work. That's just plain bad (or nonexistent) project management.
  • my wtf 2009-02-17 11:28
    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.
  • bohica61 2009-02-17 11:30
    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.

  • Auction_God 2009-02-17 11:37
    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 2009-02-17 11:37
    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 2009-02-17 11:37
    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 2009-02-17 11:41
    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 2009-02-17 11:41
    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 2009-02-17 11:41
    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 2009-02-17 11:45
    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 2009-02-17 11:46
    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 2009-02-17 11:46
    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?
  • KenW 2009-02-17 11:49
    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 2009-02-17 11:55
    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 2009-02-17 11:55
    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
  • jasmine2501 2009-02-17 11:59
    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 2009-02-17 12:02
    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 2009-02-17 12:07
    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 2009-02-17 12:09
    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 2009-02-17 12:14
    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.
  • pscs 2009-02-17 12:15
    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 2009-02-17 12:20
    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.
  • KenW 2009-02-17 12:20
    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 2009-02-17 12:21
    What an incredibly boring, tedious, and unsexy WTF article that was.
  • SomeCoder 2009-02-17 12:21
    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.
  • hatterson 2009-02-17 12:29
    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.
  • YourNameHere 2009-02-17 12:30
    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 2009-02-17 12:34
    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 2009-02-17 12:44
    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.
  • YAYitsAndrew 2009-02-17 12:49
    ha ha, I program video games for a living
  • savar 2009-02-17 12:50
    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
  • Robajob 2009-02-17 12:51
    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.
  • method1 2009-02-17 12:54
    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 2009-02-17 12:59
    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 2009-02-17 13:04
    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.
  • savar 2009-02-17 13:05
    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 2009-02-17 13:13
    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?
  • BentFranklin 2009-02-17 13:13
    Good article by Alex and really good comment by Mr. Chow.
  • Tzimisce 2009-02-17 13:14
    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 2009-02-17 13:16
    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 2009-02-17 13:17
    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...
  • DaveK 2009-02-17 13:21
    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- 2009-02-17 13:29

    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 2009-02-17 13:29
    Code should be as simple as possible, but not simpler.
    I think that summarises the article as simply as possible.
  • Was Programmer 2009-02-17 13:34
    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() 2009-02-17 13:37
    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.
  • Alex Papadimoulis 2009-02-17 13:41
    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.
  • Michael 2009-02-17 13:46
    Visual Studio? sexy? I cannot see how one can see that POS as sexy, given its performance when I'm just trying to edit a file.
  • mh 2009-02-17 13:47
    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 2009-02-17 13:49
    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.
  • WayneCollins 2009-02-17 13:49
    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.
  • WayneCollins 2009-02-17 13:52
    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.
  • Alex Papadimoulis 2009-02-17 13:57
    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?


    No matter how many tiers/frameworks/libraries you throw at it, there are always two pigeons (user-friendly representation and data-friendly representation), and you have to build two holes. With ORM (depending on your definition, etc), you get a hole for free, but it always comes with its own pigeon (e.g. middleware-friendly representation).


    savar:
    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?


    How does the formatting work: 440-243-6737, 1 (440) 243-6737, 4402436737, or all? Do you allow for 000-000-0000? What about allowing for 555 area code? What exchnages that list 911 or 411? What about...___? In the end, you end up with a function signature that would effectively look like this:
    isUSPhoneNumberValid( bool includeAreaCode, bool requireParens, bool allowDashes, bool allowParens, ... boolDissallow911Exchange, ...)

    Yes, you could use a command pattern, etc, but it's the same difference. The real problem comes in when someone would have to maintain that library... what happens when a bug is introduced with a weird combination of options to the Universal Validator? What happens when users disagree about what parameters mean? Etc.

    It's just easier to go on over to RegExLib, copy/paste the validating code that suits your needs, tweak it, and there you go. That's as universal of a validation library as you'll ever find.

    No, it's not nearly as exciting as dreaming up the Universal Library, but so goes our life as a business software developer.
  • patmoore 2009-02-17 14:08
    I understand the general sentiment of the article:

    Be an "artist" in your own time.

    I have seen way too much code where there is 5 different ways of doing the same thing.

    However, if the job is boring then as a manager you will get mediocre people producing mediocre code with mediocre results.

    And mediocre people rarely consider the business needs, they just do what they are told to the letter of the spec. Mediocre people don't look for that open-source library that already does 90% of the code.


    As for me, my rule : be lazy. Make the code so someone else can fix boring bugs. When the sales tax rate changes in Reno, nevada - make the code so the product manager can make that change. So the person with the boring fix request can fix it themselves!

    If I can tell a non-programmer-type, make the change yourself by altering this config file -- they are amazingly happy about the power they have.

    So my advice is to go nuts with config files. Make the program as data-driven as possible.

    Ironically, done well, this results in clean code and less boredom.
  • Nobody 2009-02-17 14:09
    I learned 90% of what I know about programming "on the clock".

    Showed up to my first paid programming job and discovered I was going to have to use a language I had no experience in. I bluffed my ass off. Stopped by a bookstore on the way home and picked up a book on that language. Over the next two weeks I learned the language and completed the project.

    Lets just say I don't recommend it.
  • dxmio 2009-02-17 14:16
    Open source development in your free time is a nice way to counter-balance tedium.
  • DaveK 2009-02-17 14:20
    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.
    Actually, the comparison between bad programmers and rockstars is more apt than you think.

    Real musicians laugh at rockstars; musical geniuses à la Mozart they aint. They generally can't read music and don't have any serious compositional skills, they can usually bash out a three-chord trick and that's about the limit of their abilities. Great at screwing up their faces and looking all emotional while widdly-widdly-widdling a short run up the blues scale, but ask them to compose a counterpoint and they're hopelessly lost.

    Similarly, professional coders laugh at "rockstar" coders. They have a few neat tricks that look flashy, but they don't even realise that there are a whole class of professional skills above and beyond learning a few "neat tricks". They're great at posting and boasting about how cool they are with their latest bit-twiddly-widdly-widdly algorithm, but ask them to architect a relational database architecture and they're hopelessly lost.

    Oh, and they both suck lots of cock.
  • Pedro 2009-02-17 14:23
    I must admit that I do get a thrill when I finally figured out what was causing the code to break.
  • hatterson 2009-02-17 14:28
    DaveK:
    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.
    Actually, the comparison between bad programmers and rockstars is more apt than you think.

    Real musicians laugh at rockstars; musical geniuses à la Mozart they aint. They generally can't read music and don't have any serious compositional skills, they can usually bash out a three-chord trick and that's about the limit of their abilities. Great at screwing up their faces and looking all emotional while widdly-widdly-widdling a short run up the blues scale, but ask them to compose a counterpoint and they're hopelessly lost.

    Similarly, professional coders laugh at "rockstar" coders. They have a few neat tricks that look flashy, but they don't even realise that there are a whole class of professional skills above and beyond learning a few "neat tricks". They're great at posting and boasting about how cool they are with their latest bit-twiddly-widdly-widdly algorithm, but ask them to architect a relational database architecture and they're hopelessly lost.

    Oh, and they both suck lots of cock.


    And, as with real rockstars, the "rockstar" coders make crazy amounts of money as pointless consultants.
  • Code Dependent 2009-02-17 14:31
    Dirge:
    If you can't use your professional skills at all in your hobbies, then IMO you are probably in the wrong line of work...(snip)...in general I think it's pretty sad when someone has *no* outside interest in what they do professionally.
    I got started doing programming as a hobby. It was enjoyable enough, and I got good enough at it, that I decided to make a career of it, so I went to college (at age 37), got a CS degree, and started doing it for a living.

    I work a salaried 40 hour work-week, give or take a few hours here and there. At the end of the day, I've had enough software development to satisfy my hobbiest's interest in it, and then some. At the end of the week, even more so.

    I have a very nice, well-outfitted woodworking shop where I build things. I play drums. I play Native American flute. I garden (flowers, vegetables and landscaping).

    I no longer have a hobbiest's interest in programming. After 40 hours a week of it, I'm ready for other interests to occupy my time. I've seen the guys who do it at work and then go home and do it after hours. They're generally as white as a catfish belly from staying inside 24-7, pimple-faced from living on Dr. Pepper, pizza and potato chips, overweight from lack of exercise plus said diet above.

    40 hours of it is enough for me.
  • Franz Kafka 2009-02-17 14:31
    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.



    the way I do it, you gather the rules like this and externalize the common ones (parameterized by state only, f'rinstance) into a properties file. This is so you can reduce your codebase and add new rules by editing one line in a file. More complicated conditions are left alone until they're enough of them to matter
  • Joe 2009-02-17 14:37
    Thanks for the article. It resonant with many of my frustrations over the years.

    I've always started out wanting to write that brilliant system (that just happens to be a web based invoicing module) but after I get my arms dirty I find myself wallowing in domain specific rules and double checks all intertwined within my beautiful MVC framework. If I could only figure out a way to abstract the biz rules out of my beautiful pristine computer science abstractions. Many experts say its possible and if you don't do it your a knitwit. I always fail and end of taking solace in the fact that if I can put a smile on the face of the invoicing agent then I've done my job. The users don't know what's under the hood but they do know good software when they see it (from their perspective).

    The really smart people shouldn't give up on solving the issues. Future systems will be better and will evolve toward the ideal. In the meantime a draft horse like me is going to try the best I can to get it done on time, under budget, and fully functional: all of which are going to involve some obscene code.

  • Nix 2009-02-17 14:41
    Just today! I was frustrated with my current project of workflow system for company's internal use. Technology was selected by employer and looks ugly for me. A heavy monster from 90s, that provides modifications only via VBScript. This makes me sick and depressed. I think I'll use the last advice from your article. I totally agree with you, that is business... Thank you!
  • WayneCollins 2009-02-17 14:47
    Now I have allieviated boredom and frustration by taking a "Classic" ASP codebase and migrating it to a newer platform... once to Java and once to .NET

    That turned out to be a win for me and the customer... my code got less buggy, less frustrating, and less boring, and their app became more stable and more flexible.

    Sometimes you need to take the time to get better tools before you start work. Sometimes the project isn't big enough for that up-front work to pay off...
  • Lego 2009-02-17 14:49
    DaveK:
    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.
    Actually, the comparison between bad programmers and rockstars is more apt than you think.

    Real musicians laugh at rockstars; musical geniuses à la Mozart they aint. They generally can't read music and don't have any serious compositional skills, they can usually bash out a three-chord trick and that's about the limit of their abilities. Great at screwing up their faces and looking all emotional while widdly-widdly-widdling a short run up the blues scale, but ask them to compose a counterpoint and they're hopelessly lost.

    Similarly, professional coders laugh at "rockstar" coders. They have a few neat tricks that look flashy, but they don't even realise that there are a whole class of professional skills above and beyond learning a few "neat tricks". They're great at posting and boasting about how cool they are with their latest bit-twiddly-widdly-widdly algorithm, but ask them to architect a relational database architecture and they're hopelessly lost.

    Oh, and they both suck lots of cock.


    Mmmmm! Sounds like chicken for dinner tonight...
  • DaveK 2009-02-17 14:55
    Lego:
    DaveK:
    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.
    Actually, the comparison between bad programmers and rockstars is more apt than you think.

    Real musicians laugh at rockstars; musical geniuses à la Mozart they aint. They generally can't read music and don't have any serious compositional skills, they can usually bash out a three-chord trick and that's about the limit of their abilities. Great at screwing up their faces and looking all emotional while widdly-widdly-widdling a short run up the blues scale, but ask them to compose a counterpoint and they're hopelessly lost.

    Similarly, professional coders laugh at "rockstar" coders. They have a few neat tricks that look flashy, but they don't even realise that there are a whole class of professional skills above and beyond learning a few "neat tricks". They're great at posting and boasting about how cool they are with their latest bit-twiddly-widdly-widdly algorithm, but ask them to architect a relational database architecture and they're hopelessly lost.

    Oh, and they both suck lots of cock.


    Mmmmm! Sounds like chicken for dinner tonight...
    ITYM "It sounds like chicken, but it codes like fish"... oh NM.
  • davidyorke 2009-02-17 15:08
    Richard:
    Alex:
    This is not the type of software that changes the world. In fact, it probably won’t even put a smile on someone’s face. Its sole purpose is to add to the bottom line by making other workers be more productive.
    Actually, I'd argue that it is exactly this kind of software that changes the world. By taking care of the mind-numbing tedious tasks that used to employ scores of people at most "real companies," <snip>


    This is the whole reason computers EXIST in business, to increase productivity and profits. Look in an old dictionary and you'll see "computer" defined as a PERSON who does calculations. The introduction of Von Neumann inspired machines into organizations (business, government, etc.) meant that not only did people not have to calculate, but they don't have to do MYRIAD things that used to be done by hand (type invoices, route memos, map routes, etc.).

    The technology of software development is fascinating, for sure. But what its PRODUCTS (e.g.: OLPC, mapping the human genome, the Internet) allows human beings to accomplish and its effects on society are truly awesome.
  • Thrash 2009-02-17 15:15
    I code for the discovery aspect. I like to invent and discover new ways of doing things. This is where i get job satisfaction from. I would never code an app now days the same way as i coded apps a year ago. I'm constantly trying to out do myself.
  • Anon 2009-02-17 15:24
    The UI defined by the database? Reminds me of some place where a very clever programmer was tasked with being the architect of the 'next gen' rewrite of an existing VB6 app that was being sold by them. He was told by the CEO to make sure it 'did everything', meaning it was as configurable as possible (and then some). Rather than argue with the CEO for a proper spec of the business requirement, he thought he was clever enough to do this. Trouble was, he never stopped to ask himself why this app was not already on sale on a shelf near you. Because although theoretically possible, the app would never really work in a business environment, mainly because of maintenance difficulties of the UI data. Needless to say, the development bogged down as the developers struggled to use the 'system that did everything', and last I heard was still struggling to deliver.
    Still, the architect was only guilty of pride and naivety. At least he wasn't lazy, dishonest and generally cankerous, as some others are.
  • Andy Freeman 2009-02-17 15:30
    > 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.

    Tedium may be inescapable, but defining something multiple times pretty much guarantees that at least one of the defintions will be wrong and takes more time than defining it once.

    Normalization isn't just for databases.

  • Maciej 2009-02-17 15:37
    Jon:

    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.


    I agree completely. The arguments and examples given in the article boil down to a bunch of straw-men. "What if you have a document that only AZ and TX care about, and it will never change?!" Well, then your contrived example would be perfectly fine. In reality, it would probably be a lot more practical to let the user choose per-state documents that need to be attached, and add a ->getStateDocuments() method to your record object or whatnot. Likewise, a simple configuration options somewhere for your maximal ledgerAmt is not exactly extravagant, and is probably going to get you kudos when tax laws change, and you can inform your boss that your clients don't have to wait until your next build cycle to get their application in line. There is a whole lot of ground between hardcoded business logic and crazy natural language parsing "guess what I'm thinking" systems.

    If you find your self writing the same code day after day, or copy/pasting all over the place, and further think that this is the normal state of things, then I most definitely do not want to work with you. Your job is to *organize* your program's logic in a way that is suited to your business requirements, and resilient to changes, not to slap together whatever crap generates your form fields correctly.
  • pink_fairy 2009-02-17 15:48
    Anonymouse:
    Yea, that's it. I think I'm going to be unsubscribing.

    This article is supposed to be what, exactly? Enlightening?
    Not really. Aspirant Boddhisatvas should look to other web-sites, of which I am told there are many. This is more of a POV, and it's fine as such.

    I'm puzzled by this notion of "unsubscribing." How can you unsubscribe, when you don't pay any money and you post anonymously? Is this some sort of Zen paradox? If you mean "I think I'm going to cancel my RSS feed," well, that'll cause real ructions around here. Try sticking pins in an Alex doll -- that's about as much use.

    Anyway, two observations on the original article (which was fine by me):

    (1) It's obviously written by someone who programs predominantly on Windows. (No flame here. I've done my fair share of Windows programming. I know the feeling. It's not a necessary function of Windows programming; it just seems to be a cultural artefact.)
    (2) The thoughts transfer remarkably well to maintenance programming in general, which is what 80% of us do. It's noticeable that many of the supportive posts come from maintenance programmers. As far as I can see, many of the less supportive posts come from blithering idiots^W^W the Framework Astronauts who cause us maintainers the problems in the first place...
  • Mr A 2009-02-17 15:49
    This article makes sense. Hooray for Alex.

    A typical cycle in IT goes something like this:
    - We'll make it future proof - let's avoid the need to redeploy the whole app just because some codes change by putting the business rules in the database. Good idea...

    - then the business rules change and we discover that the DB structures don't meet the new requirements. Ah well...

    - So we change the DB schema and have to release the whole app to deal with the new schema. Doh.

    More work for nothing.

    <rant>
    Over the last 10 years, I've worked with a few truly exceptional developers; articulate people with talent, drive and a knack for completing tasks quickly and efficiently. The rest I've worked with have mostly been:

    * divas who believe their work is great art that shouldn't be sullied with trivial business needs;

    * socially inept train enthusiasts who can code in C, but live with mother and can't boil an egg; and

    * downright rude and abrasive bone heads unable to grasp basic concepts like usable interfaces, simple process, other peoples' unwillingness to die for IT and (most strikingly) soap.

    It's taught me one important lesson...

    I hate them all. Every last whining, socially contagious, graceless, boring knuckle head. Why is IT an enclave for people who don't get relationships? Please bring me something that works, is simple to use and, for bonus points, can be maintained. If you can't manage the 'works' and 'is simple to use' part, the elegance of the code becomes academic.

    I'd rather have a clumsy VBA app written by a rough engineering type, than an elegant Java program cunningly fusing FORTRAN and deep LISP that wins awards on coding sites BUT DOESN'T ACTUALLY DO WHAT I F****NG ASKED.

    And yes I do change my mind when I see the delivered product, as do all the customers. That's why we have short development cycles, agile processes and the like. We want our software to change and STAY USEFUL.

    I bend over backwards to embrace best practice and good management techniques. It's dull and I'd rather be with my family frankly but if I'm willing to adapt to the needs of developers, why can't you adapt to the needs of the business?

    My 'boring business' keeps you in Hush Puppies and Linux magazines. Please shut your noise and build something that works. Otherwise find someone else to give you money.
    </rant>
    Am I being unreasonable?
  • pink_fairy 2009-02-17 15:52
    dxmio:
    Open source development in your free time is a nice way to counter-balance tedium.
    Some people, when confronted with tedium, think "I know, I'll do some open source development." Now they have two tedia.

    Mark you (or perhaps Jamie you), at least they're balanced.
  • Pet 2009-02-17 15:52
    Dirge:
    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.


    Why not?

    Seriously, in any case, irregardless if this logic is in the application code or some friendly configurable UI, none of the customers will touch it themselves anyway.

    In any case, the trivial change will be performed and tested and deployed everywhere by your development/testing/deployment people, and a full recompile is an insignificantly small amount of time compared to that.

    The customers will either get the change in a scheduled update or will file a ticket to you saying 'Oregon changed the taxes in 2010 and now nothing works!!!' - even if there is a huge red window with a description 'Put Oregon tax rate here'.


    So, in the end, the only issue that counts is if it is cheaper for your company to maintain the rule written in a function or the rule written in some database + the database interface in the code. It might be one way or another, depending mostly on the number and similarity of the rules, are they structurally the same or with wildly different logic for every rule.
  • KattMan 2009-02-17 15:53
    [quote user="savar]
    Agreed. I hate the term "rock star" programmer. If such a thing exists, I've never met him (or her).
    [/quote]

    I'm a rockstar programmer, notice no quotes there. I lived off my music for two years before the band imploded. After that I became a programmer. So maybe I'm more an ex rockstar programmer.

    I do have to say, the girls were more numerous when I was a rockstar.
  • Greg Webb 2009-02-17 15:58
    EvaUnit02:
    This screams of amateur 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.


    Sorry, but I've got to agree.

    The best project is emphatically _not_ the one that does everything by hand. Come back to a 5-year old web project that hasn't had any thought put into the cleverness of designing a reusable semi-automated framework and has had new bits hacked onto it, and what can you get? A mess. Try changing all the forms to use a certain new stylesheet and validation function, or updating the design template so the whole site now reflects the new branding. You'll be there for weeks and the results will be poor.

    Do things properly and yes, there's still grunt work - but where the work is nothing _but_ grunt, rephrasing information from one source into another, you owe it to your successors to at least investigate whether it can be automated. Most forms can _easily_ be drawn from a database and give you a result that's consistent, maintainable, uses the best functions it can every time and just do a far better job for all concerned.

    Should we try to shoot for the moon when we only actually need a quick trip round the corner? No, but we shouldn't try to do everything by hand when we've got a wonderful machine that can do it thousands of times identically at the touch of a button if we only spend that small amount more time thinking.
  • Franz Kafka 2009-02-17 16:02
    Alex Papadimoulis:

    How does the formatting work: 440-243-6737, 1 (440) 243-6737, 4402436737, or all? Do you allow for 000-000-0000? What about allowing for 555 area code? What exchnages that list 911 or 411? What about...___? In the end, you end up with a function signature that would effectively look like this:
    isUSPhoneNumberValid( bool includeAreaCode, bool requireParens, bool allowDashes, bool allowParens, ... boolDissallow911Exchange, ...)


    Sure, if you're insane. What really happens is that you pass in a string and a parameter object with the things you care about set (the rest are defaulted). what you get back is a phone number object (with separate fields for area code, exchange, number, extension, flag for special codes like 911) or an exception saying couldn't parse.
  • AndyL 2009-02-17 16:02
    hatterson:
    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."

    Notice that Albert Einstein was able to express that sentiment in nine words, while Alex needed an entire essay.

    Just sayin'.
  • Jaysan 2009-02-17 16:03
    As my ex is a perfect example of, sometimes they do.
  • pink_fairy 2009-02-17 16:04
    Joe:
    Thanks for the article. It resonant with many of my frustrations over the years.

    I've always started out wanting to write that brilliant system (that just happens to be a web based invoicing module) but after I get my arms dirty I find myself wallowing in domain specific rules and double checks all intertwined within my beautiful MVC framework. If I could only figure out a way to abstract the biz rules out of my beautiful pristine computer science abstractions. Many experts say its possible and if you don't do it your a knitwit. I always fail and end of taking solace in the fact that if I can put a smile on the face of the invoicing agent then I've done my job. The users don't know what's under the hood but they do know good software when they see it (from their perspective).

    The really smart people shouldn't give up on solving the issues. Future systems will be better and will evolve toward the ideal. In the meantime a draft horse like me is going to try the best I can to get it done on time, under budget, and fully functional: all of which are going to involve some obscene code.

    Well, in case it helps, try Terrence Parr and StringTemplate. Once you're copacetic with that, your real problem is to unlearn everything people tell you about the M of MVC. It isn't just a database (with or without stored procedures). It isn't just a trendy ORM with introspection. Actually, I'm not sure what it is, but I'm damn sure it's layered, and I'm damn sure it's domain-specific. Try it on a simple business domain to start with, and see if it works.

    I know I'm going to.
  • Someone 2009-02-17 16:11
    imalc:
    Code should be as simple as possible, but not simpler.
    I think that summarises the article as simply as possible.


    Just the first line would have been a simpler summary.
  • LOL 2009-02-17 16:13
    I actually read almost 1/3 of the article... uff...
  • Charles400 2009-02-17 16:17
    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.


    That's okay. I want the hot chick in Accounting.
  • Franz Kafka 2009-02-17 16:21
    D.K.:
    I wish the business would now what they want all the time. It becomes really annoying, when you deliver the app as per spec, they play with it and decide to change the requirements, you have to throw away half of the code and cannot charge money for these changes, because in "economical crisis" you won't get more money anyway.


    Then they don't get new code. Adding new reqs/changing the world is a change order, and you get paid for those.
  • Code Dependent 2009-02-17 16:22
    AndyL:
    hatterson:
    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."

    Notice that Albert Einstein was able to express that sentiment in nine words, while Alex needed an entire essay.

    Just sayin'.
    What I notice is that both Albert and Alex expressed themselves on the subject. Where's your offering?
  • el guapo 2009-02-17 16:24
    Leo:
    As Michael A. Jackson said in his 1975 Principals of Program Design, "Programmers… often take refuge in an understandable, but disastrous, inclination towards complexity and ingenuity in their work. Forbidden to design anything larger than a program, they respond by making that program intricate enough to challenge their professional skill."


    Indeed. And as Michael J. Jackson said in his 1983 Thriller, "Billie Jean is not my lover."

    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.


    Well, he has seen fire, and I believe he's seen rain as well. Also sunny days that he thought would never end.


    And I'd like to meet one of these Principals of Program Design. As long as he doesn't put me in detention for writing lousy code.
  • pink_fairy 2009-02-17 16:29
    bohica61:
    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.
    Real Programmers bathe in the stuff. They don't just use it to repel plagues of locusts.

    Gawd, that's so Old Testament.
  • GrandmasterB 2009-02-17 16:29
    The whole screed comes off as just some cubicle monkey rationalizing why his boring job as a corporate drone is really cooler than the jobs of people who work on new and interesting projects.

    The way I see it, the 'real' programmers are the ones who keep learning and keep honing their art, even when on the job and even when, quite frankly, it's unnecessary. Its exactly that intellectual curiosity and the exposure to new concepts it brings that allows the so-called 'rock stars' to achieve things that the 'vocational' programmers toiling away on their TPS reports every day cant even dream of attempting.
  • pink_fairy 2009-02-17 16:36
    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.
    The respondent's tendency to refer to Wankipedia makes it sound like he can't even be bothered to think for himself.

    Welcome to the site!

    We have all sorts of opportunities for you here. From quoting Captchas to idolizing mythical girls on bean-bags; why, you can even submit your own code for a laugh!

    Lordy lordy -- I'm turing into KenW.

    No ... I mean, I'm turning into KenW. Unfortunately, the Gods of Typographical Serendipity preclude me from altering that statement, and sod the Edit button. I never trusted that little fucker anyway.
  • Great link for WTF source material buried in this article 2009-02-17 16:37
    That link to "Compression of Random Data" is a treasure trove of WTF material. This quote alone should get WTF of the year:

    "I agree that you can not get more than 2^N messages from N bits. No question about it. BUT THAT STATMENT HAS NOTHING TO DO WHATSOEVER WITH THE INTERPRETATION OF WHAT THOSE BITS 'MEAN'."

    Are metaphysical bits the future of computing. Do we need a new boolean operator to toggle the value stored in a bit's soul?
  • YAYitsAndrew 2009-02-17 16:44
    DaveK:
    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.


    Nothing's cool about that, which is why I'm an indie developer releasing my own designs in a company with 3 full time members total.

    Nice try at belittling me though :)
  • Mark 2009-02-17 16:55
    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.

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

    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.


    Spoken like a true, naive, optimistic, deluded, inexperienced teenager/college student.
  • Code Dependent 2009-02-17 17:06
    Mark:
    John Coleman:
    People need to suck it up and STOP bowing to their employer and start rioting in the streets for work that doesn't suck.
    Spoken like a true, naive, optimistic, deluded, inexperienced teenager/college student.
    I know when my company is hiring, they eschew Monster.com and headhunters in favor of people rioting in the streets.
  • D 2009-02-17 17:08
    Programming is my profession, but photojournalism is a hobby of mine. Capturing that magic moment like Henri-Cartier Bresson is deeply fulfilling whereas taking that group shot at a family party is personally stultifying. However over the years I tend to look back at the group shots with more fondness.

    When I program I try to keep in mind that elegance and necessary cleverness are essential for growth but that clear, boring code is nicest when looking back. I try to make sure my motivations are in the right place and go with my gut when choosing the approach.

    And I comment the heck out of everything!

  • Real-modo 2009-02-17 17:15
    imalc:
    Code should be as simple as possible, but not simpler.

    That is merely the XP motto, "do the simplest thing that could possibly work". And it is wrong. Code should be as simple as it should be.

    That sounds like some stupid pseudo-Zen. But consider this: Mastery requires you to be able to judge when things are right. As in other professions, attaining mastery takes about 10,000 hours of practice, and continual reflection and discussion with peers.

    That "apprenticeship" is the only way to be able to know all the various dimensions of change, assess the risks, and form a judgement as to which risks will be catered for and which merely carried. In other words, to be able to judge that the software is as simple as it should be.

    PS. I don't want to diss XP. On the contrary. It has many things right: the emphases on the social aspects of software development, on group learning and group ownership, on conceptual and stylistic integrity, on continual review, and on automation and repeatability, in particular. XP is a major advance in software development practice.
  • Shut Up Alex 2009-02-17 17:16
    Are you serious, grandpa? Should we get off your lawn, as well?
  • jasmine2501 2009-02-17 17:38
    Mr A:
    This article makes sense. Hooray for Alex.


    Over the last 10 years


    Yup... 10 years will teach you that what this article says is very true. I've been flamed for this before but when it comes down to experience, you see the 'older' programmers making stuff that works, and the fresh college graduates doing 'research' which doesn't amount to usable software. Business rules engines and expert systems and similar "bright ideas" are usually worthless to users who aren't engineers and programmers. Users are dumb... they don't know how to configure their word processors, and you're going to hit them with expert systems? Anyone with more than 10 years in the business world will know better, unless they are completely out of touch.

    Extensible, future-proof, modular, XXX, whatever... should be kept in the research world. As "Mr. A" said, users just want it to work and they don't give a crap how it's coded.
  • Franz Kafka 2009-02-17 17:45
    jasmine2501:
    Mr A:
    This article makes sense. Hooray for Alex.


    Over the last 10 years


    Yup... 10 years will teach you that what this article says is very true. I've been flamed for this before but when it comes down to experience, you see the 'older' programmers making stuff that works, and the fresh college graduates doing 'research' which doesn't amount to usable software. Business rules engines and expert systems and similar "bright ideas" are usually worthless to users who aren't engineers and programmers. Users are dumb... they don't know how to configure their word processors, and you're going to hit them with expert systems? Anyone with more than 10 years in the business world will know better, unless they are completely out of touch.

    Extensible, future-proof, modular, XXX, whatever... should be kept in the research world. As "Mr. A" said, users just want it to work and they don't give a crap how it's coded.


    Extensible is a good thing in moderation - my first comment here about pulling common, simple business logic into a config file is one example - you can add new rules with minimal hassle. They don't care how you do things, but they do care when you start producing work in less time with less bugs.
  • jasmine2501 2009-02-17 17:51
    But in most companies, business logic doesn't change very often, certainly not often enough to put it in a config file or database field if it means extra work. If actual business rules are being changed really often, there is a management problem that needs to be dealt with, rather than creating software that can handle out of control management. Business values change often enough to be in the database.

    The difference is (tax = price * rate) almost never changes - that is business logic. The rate in that equation should almost always be in the database or soft-coded some other way - it is a business value, and needs to be user-configurable.
  • Franz Kafka 2009-02-17 17:52
    jasmine2501:
    But in most companies, business logic doesn't change very often, certainly not often enough to put it in a config file or database field if it means extra work. If actual business rules are being changed really often, there is a management problem that needs to be dealt with, rather than creating software that can handle out of control management. Business values change often enough to be in the database.

    The difference is (tax = price * rate) almost never changes - that is business logic. The rate in that equation should almost always be in the database or soft-coded some other way - it is a business value, and needs to be user-configurable.


    Sure, the formula doesn't change much, but the list of what items are taxable and at what rate can change quite often, so that needs to be in the db if you're, say, a grocery store.
  • Matt Garman 2009-02-17 18:20
    Interesting... For me, the "learn the business" rule is critical. Once you learn the business, you'll know if the coding will be boring or not. That is, if the business is boring, then the coding will be boring. If the business is interesting, the coding ought to be fun. And whether or not the business itself is interesting is a matter of personal preference/taste.

    In my previous job, I developed, maintained and supported an extension to the Pro/ENGINEER 3D CAD program at a huge manufacturing company. Pro/E was used by almost all design engineers; my plug-in made certain designs easier (and automated some other tasks). I didn't have much of an opinion on this work until I really started asking a lot of questions, and getting a better understanding of how the design-side of the business actually worked. It made the software part a lot more relevant, if nothing else.
  • mabinogi 2009-02-17 18:23
    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.


    make
    make deploy

    or:

    ant build deploy

    or:

    ./custom_build_and_deployscript.sh

    that was _hard_ wasn't it?
  • mgb 2009-02-17 18:36
    The level of specificity in that code leads me to believe that you're being lazy rather than keeping it simple (Hardcoded strings? Really?). Pretty much every system above a certain threshhold - and in my experience that's somewhere around 100 users - is going to need a way to change the rules by changing just data, and that applies to every presentation, business logic and workflow alike.

    More importantly, if you have to recompile for a change for which you can find an analog in your development history then it's probably your own fault. Every system I've ever worked on (and wow, have they ever been boring) has eventually run into a need for frameworks for Custom Fields, Validation, UI decoration (not generation, really, although that's come up often enough to be notable), Dynamic Report Engines, and a ton of other stuff that you'd probably look at as being "Sexy". There are whole sets of problems that should be regarded as "coming eventually" for pretty much every developer.

    I'm a maintenance programmer, but I know for a fact that businesses change often, and that maintaining software in a properly forward-looking way means anticipating what classes of change you need to be planning around. That's where the sex comes into maintenance - watching a whole class of business-hobbling problems disappear after a well-planned and incrementally executed change regime.
  • Steeldragon 2009-02-17 18:36
    thanks for the informative article.
  • vr602 2009-02-17 18:37
    Ok I read the article but I haven't read the 4+ pages of what everyone else wrote. As to the article, well, yes. I understood all of this 20 years ago (no really). Where's the surprise? If any of you find this surprising or unacceptable, then you are either very young, or very ignorant. Alex, if you want pages more of platitudes about how IT works, just ask me. Yawn.
  • randomo 2009-02-17 18:40
    "Find Satisfaction Elsewhere"

    Sometimes the best satisfaction can be had from simply talking to one of the users.

    E.g. To the programmer it's an extremely dull application. To Jack and Jill in the admin department, it's the thing they've been waiting for. It's nirvana. It takes an excruciating task and replaces it with a few clicks.

    Knowing that your work has made someone else's life a little less tedious can be quite satisfying.
  • Paula Bean 2009-02-17 18:46
    "7. Get Another Job. Maybe you’ve reached your value apex. Or maybe you’re just sick this type of development altogether. Either way, there are plenty of programming opportunities out there that don’t involve boring, information systems. Of course, the competition is much fiercer since the Paula Bean-types seem to only fly under Corporate IT's radar."

    Damn it... But what do I do when I've exhausted all corporate IT options???
  • vr602 2009-02-17 18:47
    GrandmasterB:
    The whole screed comes off as just some cubicle monkey rationalizing why his boring job as a corporate drone is really cooler than the jobs of people who work on new and interesting projects.

    The way I see it, the 'real' programmers are the ones who keep learning and keep honing their art, even when on the job and even when, quite frankly, it's unnecessary. Its exactly that intellectual curiosity and the exposure to new concepts it brings that allows the so-called 'rock stars' to achieve things that the 'vocational' programmers toiling away on their TPS reports every day cant even dream of attempting.
    Ok, so I don't want this guy working anywhere near me.
  • Jason Gorman 2009-02-17 18:52
    You're quite right that we should do the simplest thing possible to satisfy the business requirements. Being test-driven all the way up to business acceptance tests helps enormously, as does continuous refactoring to keep your code clone and easy to understand.

    But I think I spotted one classic refuctoring in your example -> "stating the bleeding obvious". i.e. Comments that paraphrase the code :-)
  • Barf 4Eva 2009-02-17 19:10
    Man those words ring true for me... Couldn't agree more.

    You are lucky, btw... I wish I was only working 40 hrs/wk...

  • HB 2009-02-17 19:11
    Amen!!
  • emcoffey3 2009-02-17 19:32
    I really don't think there's a fine line between when business logic should be hard-coded and when it should be left in the hands of the user. Where I work, the business rules change all the time. We try to make everything we write as dynamic as possible, and are successful much more often than not, but there are always some things that have to be hard-coded.

    I must agree with most of Alex's article, though. You should learn technology on your own (to some degree at least) before you start using it in a work project. And you shouldn't re-write anything just becuase there's newer technology available. We currently support a Windows application that was hastily ported from Delphi to .NET (bugs and all!) by an outside consulting company for no apparent reason. I later found out that it was their first .NET project, and we were their unfortunate test subject. Needless to say, it's a nightmare.
  • Robert Dole 2009-02-17 19:52
    I disagree with a lot that is said in this article, actually. I remember a class assignment where we had to work together as a team to implement a backend to a particular GUI application. One section of the GUI happened to require a lot of mind-numbingly tedious and repetitive code to hook up the GUI to our backend model, and it was fortunately assigned to one of my partners. He took the standard C approach of typing everything out manually and ended up with a lot of similar-looking code. It turns out he also ended up with a lot of bugs which were very subtle and difficult to find. He never got all the bugs worked out, in fact.

    Fast forward to another part of the assignment. I ended up having to work with the same section of the UI and write similar tedious code as described above. However, I took a different approach to solving the problem. As our assignment's language was Java, I took the time to learn JRuby and figured out how to use Java's reflection API with JRuby to autogenerate the code I would have to write by hand, and even autogenerate some unit test code for it. It probably took me longer initially to fgure out everything and get the code generator working, but in the end, ALL of my code worked, because it was a computer that was generating it.

    There are certainly disadvantages to code generation techniques, as whenever the code had to be smarter I had to make the code generator smarter as well, but in the end I was able to pass off my section of the code without any problems, and I did it by learning a new technology and applying it to what could have been a tedious, boring, and error-prone task.

    I've applied the same idea to my professional career so far and it has lead to a lot of bug-free code, code that would have taken a long time to debug manually. My philosophy is, if a programming task is boring, figure out a way to automate it. That's what computers are for! They perform repetitive tasks far more accurately than we as humans could.
  • Adam Turner 2009-02-17 19:56
    I agree with most of this article except for the "understanding the business."

    Even in ad hoc environments, programming is programming and business logic hasn't changed much since its inception. I'm always amused when I get a call from a health care company with the bad news that they're looking for someone with a health care background. My response is always, well I thought you were looking for a programmer. After speaking with programmers in the health care industry and others, it becomes quickly evident that the code lacks an experienced tenure. Performance optimization, for one, is replaced with vocabulary.

    In my experience, you generally have to first strive to understand and then to be understood. Once that is acheived, you end up explaining the necessary additional logic that's required to ensure integrity. In other words, paraphrasing the 'full' business logic that was overlooked by management or somehow was absent in the requirements docs.
  • Stilgar 2009-02-17 20:05
    Sometimes when I am workig on boring government information systems I lose motivation. In these moments I remember how some stupid, ugly middle aged woman in the government administration made me fill out several copies of a stupid paper form by hand and then acted as if she is paying my salary and not the other way around because it just happened that in this particular case I depended on her because I needed the stupid documents signed and stamped. Then I remind myself that she or some other like her will be kicked out (or at least relocated) because when my project is deployed people will be able to fill the forms online and get digital versions of the documents. Someone will be saved from stupid clerks. And then I get back to coding and I am happy.

    I just hope that people don't get mad about my software the same way I get mad about administration workers.
  • Peter-Frank Spierenburg 2009-02-17 20:31
    "The true rockstars can deliver software before deadlines, under budget, and that does exactly what the business needs."

    Anyone (who wants to) can deliver software before deadlines, under budget, that does exactly what the business needs. Just ask any second-year university student with an assignment due...

    If thats called being a rockstar, then I (to stretch your metaphor) must be the roadie. After the rock star is done with his set, has smashed his guitar into the stage, doused it with lighter fluid, and set it ablaze, its my job to clean up the mess. Please keep your rockstars off my projects.

    Peter.
  • Scott 2009-02-17 20:38
    I agree with the crux of article that the primary consideration in designing programs should always be to fulfill the needs of the client in the most effective means possible rather than being guided by one's own interest. However, the hard line taken against learning on the job and the tone regarding novel technology or clever techniques is limiting.

    I have worked in environments where this is the prevailing ideology and the results are not good: unmaintainable code that is literally 95% or more longer than necessary (wallpaper), over-reliance on manual processes that consume substantial amounts of time, and outright lack of ability to solve novel or complex business problems. All resulting from people unwilling to spend an occasional few minutes to explore and learn something new.

    The key is balance. Clearly the time to experiment is not when stakes are high or deadlines are looming, but in most cases when I have set aside time to experiment and tinker the net result has been an substantial net gain for my organization. In cases where I am not seeing a net gain materializing, I check myself and cut back accordingly. But the key is putting the interest of the employer first and using good judgment.

    Moreover, to argue that all this learning should be occurring at home is unrealistic. I can't bring home the data or software I work with (nor is it feasible to purchase a home copy of most enterprise software that I work with). To the extent possible, I play around at home as well, e.g. with open source software, but the issue remains one of balance.
  • Vic Tim 2009-02-17 20:40
    Crapton? How about fuckton... when it's bad, you say "Crap!" and when it's really bad you say "Fuck!" I propose that a thousand craptons should be a fuckton.
  • Barf 4Eva 2009-02-17 20:52
    Peter-Frank Spierenburg:
    "The true rockstars can deliver software before deadlines, under budget, and that does exactly what the business needs."

    Anyone (who wants to) can deliver software before deadlines, under budget, that does exactly what the business needs. Just ask any second-year university student with an assignment due...

    If thats called being a rockstar, then I (to stretch your metaphor) must be the roadie. After the rock star is done with his set, has smashed his guitar into the stage, doused it with lighter fluid, and set it ablaze, its my job to clean up the mess. Please keep your rockstars off my projects.

    Peter.


    Dude, without the rock star, you wouldn't have a mess to clean up. Much less a job title of roadie...

    We'll see a lone man, the roadie, with his nice clean stage... But no one will come to see it. Why? Because the guy smashing the guitar made it all the worthwhile.

    So, what I'm saying is, that the crazy nutball who wrote our sprawling complex of "rockstar" code gives a roadie such as myself PLENTY of work to do for ages to come...

    At the same time, I'm sick of being a roadie. Maybe it's time to move on.
  • Paul Snow 2009-02-17 21:08
    Yeah, they set me up on a project with a pile of decision tables, all hand done by some previous vendor, and expected my team and I to pound out code from them.

    Instead, I wrote a system that enabled an English like syntax, and could compile and execute the decision tables directly! Now suddenly I was EXECUTING the specification rather than coding from the specification and having to argue that my implementation does what their incomplete specification specified!

    Now after rewriting the Rules Engine three times (twice for HHSC in Texas on the Texas TIERS project, and once from the ground up for the OFAST project in Ohio), I finally wrote it for myself, and slapped an open source license on it (Apache 2.0). The project, DTRules, is now established as open source, and I am finally using it on my job in a way that won't bind it away in obscurity in the hands of some other company or government agency.

    So the moral? Sometimes you can take those boring "code the business rules" kind of jobs, and turn it into fun stuff! Write an Interpreter! A Compiler! Develop a methodology! Develop your own Patterns!

    And #$%#$@#$ all, stop throwing all your code into one honking %^@^@$%#$@ method and claim your implementation is object oriented!
  • Franz Kafka 2009-02-17 21:12
    Barf 4Eva:

    Dude, without the rock star, you wouldn't have a mess to clean up. Much less a job title of roadie...

    We'll see a lone man, the roadie, with his nice clean stage... But no one will come to see it. Why? Because the guy smashing the guitar made it all the worthwhile.

    So, what I'm saying is, that the crazy nutball who wrote our sprawling complex of "rockstar" code gives a roadie such as myself PLENTY of work to do for ages to come...

    At the same time, I'm sick of being a roadie. Maybe it's time to move on.


    Nah, the metaphor is broken; without the rockstar, you get some group like rush (who are rock gods, not some primadonna with 3 chords under his belt) and the roadies knock off at 11 and do drugs on their bus instead of bribing the event manager into not suing the band.
  • Andrew Way 2009-02-17 21:51
    Guess what? I read this article exactly as it was intended. I don't have squillions of hours to find, learn and use the current flavour of the month framework/codegen, etc, etc.

    I'm a business owner, so I look at code like a business owner - does it return on it's investment and what is the total cost of ownership?

    So, when I have a developer who "optimises" an import routine and reduces it by 60%, taking 2 full days to do so and comes to me all so impressed... I remind him the import routine is run once a month and took 3 minutes before he optimised it. So for 2 days wages (a.k.a. 2 days delay on the project) to save the customer... 21 minutes a year. Common sense seems to be all so uncommon now.

    Needless to say, our business doesn't code for customers anymore - I work on our internal systems and absolutely love every second of it. Programming to help my staff do their job better!

    Keep up the great articles and WTFs!
  • Code Dependent 2009-02-17 22:40
    vr602:
    I understood all of this 20 years ago (no really). Where's the surprise?
    The surprise is in the eyes of those who were 10 years old or younger 20 years ago. Do you think the whole human race is supposed to know something because you know it?
    vr602:
    If any of you find this surprising or unacceptable, then you are either very young, or very ignorant.
    You figured that out, did you? Wow... perceptive.
    vr602:
    Alex, if you want pages more of platitudes about how IT works, just ask me. Yawn.
    I'd prefer he didn't. For someone who trumpets his knowledge and flaunts his ego as much as you do, you are surprisingly dense.
  • Zack 2009-02-17 22:45
    Hey, there's better name for 'boring' software that you mentioned.
    Enterprise software. Better right?
  • DaveK 2009-02-17 22:46
    vr602:
    As to the article, well, yes. I understood all of this 20 years ago (no really).
    No, of course we believe you, why shouldn't we? It was already 20 years-old news even back then.
  • DaveK 2009-02-17 22:48
    Andrew Way:
    I'm a business owner, so I look at code like a business owner - does it return on it's investment and what is the total cost of ownership?

    So, when I have a developer who "optimises" an import routine and reduces it by 60%, taking 2 full days to do so and comes to me all so impressed... I remind him the import routine is run once a month and took 3 minutes before he optimised it. So for 2 days wages (a.k.a. 2 days delay on the project) to save the customer... 21 minutes a year. Common sense seems to be all so uncommon now.
    Hi! I'm a professional, not cowboy, developer - so I look at it the same way. There are plenty of us around, but we don't make as much noise as the squealing primadonnas, so maybe it's not always obvious.
  • Ian H. 2009-02-18 00:02
    “any damn fool can write code that a computer can understand, the trick is to write code that humans can understand” - Martin Fowler
  • Fred 2009-02-18 00:17
    yeah, this will get printed and hung on my cube wall
  • anonymous 2009-02-18 00:26
    Dude, you've never worked on a product that had paying customers, have you? When you release patches to paying customers, (be they binary or source code) you need to create the patch (whose time can be minimized but not removed - and, in some cases, can't even be minimized, if the tool that you're stuck with is bad), write documentation (installation instructions, what's fixed, etc.), handoff testing (which, properly done, requires installing the product & patch just like a customer would), QA (which, again, requires installing the product & patch just like a customer, but with more scenarios than handoff testing), and the actual release; then many customers like to QA a patch before they install (which means that the customer will be installing once (or more) for testing, and then again for production).

    Just because it's trivial for a single developer to patch a single test system doesn't mean that the whole process is trivial. The more configurable a product is (which requires QA up front, to confirm that configuring it works properly) the less maintenance effort is necessary. And, if you ever spent any time learning about the product lifecycle, maintenance is one of the most expensive parts of the product's life - cost which can be eliminated by fixing things earlier.




    mabinogi:
    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.


    make
    make deploy

    or:

    ant build deploy

    or:

    ./custom_build_and_deployscript.sh

    that was _hard_ wasn't it?
  • Marshall 2009-02-18 00:34
    In my first job I built a wondrous program beloved by the customer. Unfortunately a year later the customer wanted a change and I found that my code was so wondrous that I couldn't understand it.

    However now (old and grey .. albeit before my time :-) I work in an environment that personifies the old adage that if you can get the customer to slice his wrist and sign off the specs in blood as inviolate, then you've probably got about 24 hours before the first "minor" change request comes in.

    So everything is designed and coded on that assumption. If I'd written the application to the article's level of simplicity then it would have been completely rewritten many times over the years.

    Basically I code and document in the expectation that I'll be required to change something in a tight time frame and when enough time has passed that I have absolutely no memory of writing the original code. So lots of comments and longish variable names and holding intermediary results in local variables so it will be easy to follow the logic.

    But yes .. over the years I have also developed a "toolkit" of classes and routines that are more complex than was strictly required for their original purpose. They have more than paid their way in simplification of later code.

  • Kermos 2009-02-18 00:40
    Well I recently picked up a nice side project that definitely goes into the fun and sexy part of coding. Writing firmware for a device that does automotive performance tuning. =)

    I mean, think of it this way, I have a bug in my software and theoratically connecting rods *could* be peeking through the side of a block.

    I actually used to previously work for this company before I had to relocate and actually had *just* such a bug in my software that edited the mass-airflow curve. Luckily, the engine lived!
  • lolwtf 2009-02-18 00:43
    Nobody gets paid to write the "sexy" popular stuff, because it's all open-source.
  • Robert 2009-02-18 00:50
    If you're going to torture a programmer, threatening them with CP/M really isn't the worst of things. Why no go for the gusto and make them work in COBOL. I mean if you want them to feel pain and pull their eyes out...

    If you're really a Sadist I hear there is even a COBOL.Net
  • sonofusion82 2009-02-18 01:22
    As unexciting as it may be, it’s our job to do work *exclusively* to benefit our employer, not for own personal satisfaction. That’s just what it means to be a professional.


    I remember reading some Garfield comic that says something like:
    "Work is so bad that they have to pay you to do it"
  • Marc 2009-02-18 01:28
    I think there's a missing element to this, and that's scope creep.

    There's a fine line between cleverness and modularity and good programmers can tell the difference. Making it robust enough so that some bizzare undocumented (and heretofore unmentioned) business rule exception isn't going to throw an error or bork the system is the 'why' of clever/complex (read 'modular') coding.

    I cannot remember the number of times I present a complete, elegant, tested application just to hear, "Oh can we have...?" Aside from being annoying (and the extra income), the request often has nothing to do with anything previously mentioned, and will be the cause of the unnecessarily complex or redundant function, the example of a future WTF CodeSOD article.

    In Alex's example of tiering, a client swears up down and sideways that they only needs admin and user tiers until someone finally remembers Wally in a satellite office in Moose Knuckle, Wisconsin who needs that in-between tier where they can do most but not all of the admin functions because the last time he deleted the transactions table.

    Of course the other side of that is not the creep from the end users "Oh can we have..." its the question from management which is, "Why doesn't it have..." They already think they overpaid us for our work, and that it doesn't have a built in teleporter/replicator for that price is some sort of colossal insult to them, the project, the founder of the company and his mother.

    It isn't unnecessary complexity we code for, it's survival. Sometimes the survival of our jobs, sometimes the survival of our sanity.
  • GreenAlgae 2009-02-18 02:08
  • ammoQ 2009-02-18 03:09
    Boredom is good. After having experienced severe burn-out syndroms, my job just can't be too boring. I'm not interested in interesting tasks anymore.
  • kronoz 2009-02-18 03:53
    I agree substantially with this, however many crimes are committed in the name of KISS - though 'clever' software is pretty awful, so is code that is so utterly inflexible such that *inevitable* changes result in less and less readable, maintainable code until it ends up a Big Ball of Mud.

    Internal software, like all software, is more useful flexible (but not *too* flexible), readable, clean and maintainable.

    That's the crux of the matter I think - good code isn't 'clever' code using some crazy algorithm written in Fortran77: good code is as simple as possible, as close to the problem domain as necessary but not so much so that changes become problematic. Good code is readable and maintainable.

    I think object orientation, patterns, DSL's, etc. etc. *do* have a place in internal software development, however it all comes down to *taste*. I think this is the biggest problem; developers lack taste and abuse these tools which are *just tools*, and not doctrines to be followed to the letter.
  • IByte 2009-02-18 04:26
    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
    [...]
    Well, those two pages were both more insightful and more inspiring than this article (sorry, Alex). Thanks for the link.
  • Stephan 2009-02-18 05:25
    At the end of the day, the best programmers are not the ones who create the most beautifully-elegant, exceedingly-innovative code.

    Yes.

    The true rockstars can deliver software before deadlines, under budget, and that does exactly what the business needs.

    Yes. Of course. They have my envy.

    And those are the type we should all strive to be.

    No! Hell, no! Some of us have to be the bad, slow, overcomplicating, enterprisey, pro-architecture morons that need modeling, abstraction and service layers, modularization and rule engines for everything.

    Because even old-school deadline-rushed, organic Information Monoliths profit from better base components, or in fact, from having base components at all. I don't say they do so all the time, but often enough to justify that kind development. And yes, they can become innovative and elegant just by that.

    Because just as you say, this kind of software is always the same.
  • pscs 2009-02-18 05:27
    anonymous:
    The more configurable a product is (which requires QA up front, to confirm that configuring it works properly) the less maintenance effort is necessary.

    And therein lies the danger!

    You make a 'business rules' system, and some eejit thinks they can change the business rules without testing them, because, after all, it doesn't need a recompile or anything.

    Changing 'business rules' on a 'business rules' system MUST have just as much testing as doing a new build of the software.

    Simple things like changing the address of a mail server won't need much testing, but that isn't what Alex is talking about.
  • chunky munky 2009-02-18 05:27
    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.


    Actually, she did!
  • Timmy D 2009-02-18 05:58
    Everyone who agrees with this article needs to get a new job.

    If your job is not challenging your skills, forcing you to think of creative solutions (and you put them in anyway because you like to, even though they're not necessary), then you're overqualified for what you're doing.
  • Brendan 2009-02-18 07:06
    I've just come from a company that made the mistake of giving an architect free reign to rewrite an old legacy application. After three years all he had to show for it was a set of tools (Which were buggy and painful to use.) to write the application and a few tiny portions of the system written along the way as proof of concept.

    It was a classic case of a huge team focusing on exciting new technologies instead of the final product.

    After scrapping the project they restarted taking the approach of slowly replacing portions of the legacy system. Unfortunately they decided to reuse the tools so that the original project wasn't a complete write-off.

    When I left there were three 10 000+ line hand-crafted XML documents to represent the database, business and UI layers, these XML files were then parsed by the code gen tools which generated the actual C# code of the application. In the search for cutting edge technology they had gone full circle from RAD tools to writing thousands of lines of code in a basic text editor.

    When I last asked about the system they were considering writing a new tool to ease the process of writing the XML in order to make the process easier.

    Give me boring, simple, well designed competently written applications over technology-for-technologies-sake any day.
  • Carlos 2009-02-18 07:57
    Dude, use rails. No more stupid validations.
  • Jason Grant 2009-02-18 07:59
    Brilliant!

    I especially like the part about aspect-oriented approach!
  • DaveK 2009-02-18 09:07
    Kermos:
    Well I recently picked up a nice side project that definitely goes into the fun and sexy part of coding. Writing firmware for a device that does automotive performance tuning. =)

    I mean, think of it this way, I have a bug in my software and theoratically connecting rods *could* be peeking through the side of a block.
    Heh, that would make a great "easter egg"!

    A guy I used to work with had previously written software for a PIC-based electric motor controller. Thing is, the motor in question consumed quarter of a megawatt and weighed many many tonnes. If he had a bug in his software, the rotor would have run out of control, broken off its mounts and flown through the air, demolishing the entire factory and killing or injuring a lot of people.

    I think he must have done sufficient testing before it went live, because he was there to tell me the tale, but hey! Turns out that it's not just nuclear power plant control systems where you can make big explosions from little bugs!
  • Dave 2009-02-18 09:16
    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.


    Amen. And on a related note, I don't care how great your code is, it is not sexy. Scarlett Johansson is sexy. Your code is not.

    The whole rockstar/sexiness thing is coming from (and probably supported by 90% of the people reading this) stereotype nerds, most of whom have probably never kissed a girl. Instead of marvelling at how much of a "rockstar" you are or how "sexy" your code is, how about go to the gym, tubby.
  • George 2009-02-18 09:24

    Just Enough Structured Analysis:
    http://yourdon.com/strucanalysis/wiki/index.php?title=Introduction

    From the author: "This is an update, condensation, and pragmatic revision of my 1989 tome, Modern Structured Analysis, which is still employed by malicious professors to torture innocent students in universities around the world."
    http://www.yourdon.com/strucanalysis/
  • Georges 2009-02-18 09:38
    This WTF (if we can call it a WTF) made my day!

    It's great to read such great, and for me even inspiring, articles on this website. And the way they got linked to those real WTFs that I all got burned into my mind :)

    I for myself am a programmer that tries cool stuff at home, while coding straight (is there a gay way to code??? :)) at work. That helps me to keep concentrated at work and deliver working software on time. Under budget? Well, I drink a lot of coffee in the office, so I don't know :)
  • myjobdoesntdefineme 2009-02-18 09:45
    she did. i don't get the stigma around geeks like me. i see very little of it in the real world, but maybe that's because i don't surround myself with shallow people.
  • myjobdoesntdefineme 2009-02-18 09:47
    it's not the fact that it's hard. It's a bad process. In the real world a build requires validation from SQA and other departments. I record in the db typically does not.
  • Imperium 2009-02-18 10:15
    Vic Tim:
    Crapton? How about fuckton... when it's bad, you say "Crap!" and when it's really bad you say "Fuck!" I propose that a thousand craptons should be a fuckton.


    You are mistaken. Assload is the metric measure, fuckton is imperial. To, it's 1327 craptons in a fuckton, but 1000 buttloads in an assload.
  • stevejobsfanboi 2009-02-18 10:38
    I think the name "Steve Jobs" has significant relevance here.
  • Jim 2009-02-18 11:04
    Well, sometime it's like sitting at the dentist. But that's part of a job, I think...
  • Asiago Chow 2009-02-18 11:24
    Alex Papadimoulis:
    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".


    I think of them as seperate attributes. Substitutional or Transformative can be Boring or Sexy.

    You can use sexy (esoteric, bleeding edge, whatever) techniques to create substitutive code...we see that every day in fact and we all agree it is bad. Why? What makes it bad? My answer: The "good" of substitution is that high-potential humans aren't doing as many mindless tasks (the other goods, greater efficiency and lower cost, are derived). In other words, it displaces workers from automatable jobs or frees them to do more important things, depending on your perspective. Sexy means longer development and higher maintenance and that means a lower net gain (less good) from the substitution because development time weighs against use time.

    How about transformative code? You can use boring techniques to create a transformative program. However, transformative code is more likely to extend the art. It is more likely to require at-the-time esoteric techniques just to solve the problems it creates. Creating Transformative software is less software engineering and more computer science. Science is sexier than engineering -- believe it or not. So you cannot instantly condemn the use of sexy techniques when writing transformative code. Instead, you let the market sort it out. If a transformative program succeeds in transforming what humans do the developer clearly chose the right mix of boring and sexy for the time.

    As for agreement, I guess my problem with the article is this: IMO Programmers who get bored writing substitutive code should, rather than accepting their fate, look for transformative projects where their creativity and problem solving abilities will be challenged. Most shouldn't do it full time any more than most musicians should quit their day jobs, but the challenge will improve their skills and perhaps reduce their frustration at having yet another business needs discussion.

    If the right solution is to buck up, accept the boredom, and do, why don't we extend that to the people whose business flow we are improving? Why don't we just tell the factory workers to keep using hand tools, tell businesses to keep manually calculating every bill and writing reciepts out longhand? Not efficient? Just lower the pay of the workers and tell them to work longer hours. Heck, people in our government have actually used the term "mandatory volunteering" recently... that sounds like a solution we can all embrace to force workers to volunteer to work weekends at no extra pay. Of course we have that pesky 13th amendment, but we can do to it what we did to the 18th. We can improve the business bottom line without writing a line of code...so long as we are willing to accept the waste of human potential it entails.
  • kirtej 2009-02-18 11:41
    thanks for this wonderful article.. i find myself a boring programmer in your words.. who is just so used to creating information systems with the tools that i have to use.. sometime they don't even work the way they are supposed to and crash many times..

    but anyway this post actually got me thinking where to get satisfaction.. i graduated with Comp. Sci. degree but while developing information systems, got more interested in learning the business that i think is the place to go further in the career. i'm fed up with my programming career and want to move on to somewhere else and looks like i can do some transition from pure IT to IT/Business..
  • Martin 2009-02-18 11:48
    I couldn't agree less. While I think is a mistake to do complex code for the only purpose of having a challenge I do think that using patterns, good design architectures or AOP helps much more the business than you might think. The great majority of the cost of a system comes from maintainance and not from the development of it. In that sense, where I work we use all these things wisely creating simple, usefull and requirements based yet fun to develop software.

    Maybe as we create transactional systems, social webs, and desktop applications maybe we are not the best example for this article but I strongly believe that using patterns, making code reusable by designing better, using AOP for example to define transactions and many other techniques that may be considered as ways to get challenge tend to make code much more maintainable and ends up with a better TCO for almost every software.

    http://martin.zauber.com.ar/
    http://blog.code.zauber.com.ar/
  • ittwo 2009-02-18 12:10
    Nope, Alex is simply a depressed, cynical and uninspired java developer.

    Sorry could not resist.

    Don't let this destroy your attitude to software development.
  • anonymous coward 2009-02-18 12:53
    Getting the job done is the bottom line, but you have to write maintainable code. Copy-pasting code because it's "easier" or "quicker" than factoring out common parts doesn't help the bottom line in the long run. "Rockstars" know when to do something quick and dirty, and when to invest in some "complexity" to save time in the future ...
  • Vic Tim 2009-02-18 13:24
    Imperium:
    Vic Tim:
    Crapton? How about fuckton... when it's bad, you say "Crap!" and when it's really bad you say "Fuck!" I propose that a thousand craptons should be a fuckton.


    You are mistaken. Assload is the metric measure, fuckton is imperial. To, it's 1327 craptons in a fuckton, but 1000 buttloads in an assload.


    Lol but shouldn't it then be buttlode and asslode? Are 1000 asslodes a shitlode? Where are my charts, hold on...
  • Matt 2009-02-18 13:32
    I agree on everything except for the part where you say bad stuff about programming ;o
  • Harrow 2009-02-18 13:58
    Robert:
    ...there is even a COBOL.Net

    Dammit. I could have lived a long happy life without ever knowing that.

    -Harrow.
  • Teh Irish Gril Riot 2009-02-18 14:01
    Code Dependent:
    I work a salaried 40 hour work-week, give or take a few hours here and there. At the end of the day, I've had enough software development to satisfy my hobbiest's interest in it, and then some. At the end of the week, even more so.

    I have a very nice, well-outfitted woodworking shop where I build things. I play drums. I play Native American flute. I garden (flowers, vegetables and landscaping).

    I no longer have a hobbiest's interest in programming. After 40 hours a week of it, I'm ready for other interests to occupy my time. I've seen the guys who do it at work and then go home and do it after hours. They're generally as white as a catfish belly from staying inside 24-7, pimple-faced from living on Dr. Pepper, pizza and potato chips, overweight from lack of exercise plus said diet above.

    40 hours of it is enough for me.


    I'm on the exact same page and couldn't agree more. I decided to post just to tell you that you're not the only coder out there with this sentiment. When I first began my career I was a > 40 hours guy all the way. Now, after fifteen years in the industry, I find that I have enough "programming fun" at work to keep me content.
  • DrFooMod2 2009-02-18 14:49
    This could not have described myself better. It almost serves as an epiphany. I just did this recently by building this Smart Client/CAB app with a WCF server blah blah blah. KISS it is from now on. Thanks for the therapy session.
  • DragonessEclectic 2009-02-18 15:44
    There's an important distinction between "this code is boring" and "I am bored coding it". Frankly, I think all code is boring to look at. It's what it does, the problems that it solves that are interesting.

    I do not enjoy programming because writing code is exciting; I enjoy programming because solving problems is exciting. It doesn't even have to be a very interesting domain; it just has to be a problem that needs solving and that someone cares about having it solved.

    I cannot disagree more about learning on the job. If you are not continually learning something and getting better at what you do, you are headed for burn-out. Humans are rarely satisfied with stagnation and mediocrity. You can almost always learn to do the job better, and you're not going to learn how to do your job at home. Home is for things that are Not Work (unless you are planning to burn out in the next five years).

    If you are bored because you are coding the same tedious thing over and over, You Are Doing It Wrong. Why are you coding the same thing over and over? Why aren't you coding it once and calling it/c&p-ing it/subclassing it over and over?

    Personally, I was inspired by "The Man Who Was Too Lazy Too Fail"; doing unnecessary extra work is stupid, and in coding, usually causes more maintenance headaches in the long run. I write code to make future maintenance easier, because either I will be doing the future maintenance, and making less work for me is good--or it will be maintained by some junior programmer with far less experience who will be calling me to ask how to fix it, which I Do Not Want to have to be bothered with in the middle of working on the next project.

    Smart design--not 'clever' design, mind you--means designing ALL the code you write to require as little hassle as possible to change the obvious things someone is going to want to change later. It will be changed later, count on it. I learned the hard way decades ago to write even my one-off, personal test programs in a modular and maintainable way, because The Boss may come along and say "Hey, that looks really useful for our field technicians! Can you deploy it to them?"

    There is, of course, a difference between smart programming and 'clever' programming. I think it's smart to have solid, bug-free, well-designed, maintainable code. I like Brian W. Kernighan's quote on the topic:

    "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

  • Mr A 2009-02-18 16:41
    Imperium:


    Vic Tim:

    Crapton? How about fuckton... when it's bad, you say "Crap!" and when it's really bad you say "Fuck!" I propose that a thousand craptons should be a fuckton.


    You are mistaken. Assload is the metric measure, fuckton is imperial. To, it's 1327 craptons in a fuckton, but 1000 buttloads in an assload.


    No, No, No!

    When will you people get it?

    Craptons and Fucktons are archaic imperial units that are confusing and not generally accepted.

    Here's why.

    12 Shitzes = 1 Crapton
    3 Craptons = 1 Fuckton
    126 Fuckton = 1 Ferfuksake
    and 24 Ferfuksakes = 1 Bush

    The correct SI units for error is the Smear.

    A decimal point out of place in a spreadsheet corresponds to about 1/8th of shitze or the simpler 24 milli-smears.
    Windows Fista is about a giga-smear.
  • Franz Kafka 2009-02-18 17:09
    Mr A:
    Imperium:


    Vic Tim:

    Crapton? How about fuckton... when it's bad, you say "Crap!" and when it's really bad you say "Fuck!" I propose that a thousand craptons should be a fuckton.


    You are mistaken. Assload is the metric measure, fuckton is imperial. To, it's 1327 craptons in a fuckton, but 1000 buttloads in an assload.


    No, No, No!

    When will you people get it?

    Craptons and Fucktons are archaic imperial units that are confusing and not generally accepted.

    Here's why.

    12 Shitzes = 1 Crapton
    3 Craptons = 1 Fuckton
    126 Fuckton = 1 Ferfuksake
    and 24 Ferfuksakes = 1 Bush

    The correct SI units for error is the Smear.

    A decimal point out of place in a spreadsheet corresponds to about 1/8th of shitze or the simpler 24 milli-smears.
    Windows Fista is about a giga-smear.


    I dunno where you got your conversions, but over here, we simplified a long time ago:

    1 metric fuckton == 1000 'oh fucks'
  • Steve R. 2009-02-18 19:18
    If professional devs HATE that kind of code so much, give it to me - I'm a business type who has been frantically trying to find a place to write just that kind of 'dull' code. Why? Because I spend a lot of my time right now creating workarounds for garbage other people wrote in systems we can't touch. Using ACL to bridge two homegrown systems together, which are each so screwy, they can't talk to each other natively. Writing a complete asset reporting package in VBA (I wish I was kidding). I document business processes, write business logic and implement it because no one else did, and now the systems and data are a mess. MY entire job description could be 'read 'the Daily WTF' and then identify which of our clients are being written about there'.
  • EmperorOfCanada 2009-02-18 20:11
    I have been exactly where this guy is. But this is a bad place; the wrong place. You don't have to write a useless expert system but you can write the best damn system ever built. This doesn't mean writing your own operating system in assembler but it might mean coming up with an interface that is just plain genius, or pushing everything (if it applies) into web services and allowing dozens of previously stovepiped systems to integrate. Or best of all you might not simply replicate the crappy paper system but jump in with the users and figure out that they really need to store less data but they need to access it while on the road with some cool iPhone app.
    If you want to have fun AND be productive you have to think out side the box, man.
  • James 2009-02-18 20:57
    I'm pretty sure though that Michael A. Jackson did not mis-spell "principles" in the title of his book.
  • Dale 2009-02-19 06:22
    Mostly agree with your sentiments wholeheartedly, except for "That 10-year old “Classic ASP” code hasn’t gotten worn out, just much less fun to maintain".

    Classic ASP IS worn out and isn't just less fun to maintain, it actually costs more to maintain than (well written...) code in newer technology.
  • Anders Bohn Jespersen 2009-02-19 08:12
    Ok, if programming is boring, you are not doing it right :-)

    A lot of the stuff that comes with the job is boring, though, such as filling in numerous spreadsheets or test reports or whatever.

    I've found this quote from actor Edward G Robinson to improve my job satisfaction remarkably:

    "The sitting around on the set is awful. But I always figure that's what they pay me for. The acting I do for free."
  • savar 2009-02-19 10:12
    [quote user="KattMan"][quote user="savar]
    Agreed. I hate the term "rock star" programmer. If such a thing exists, I've never met him (or her).
    [/quote]

    I'm a rockstar programmer, notice no quotes there. I lived off my music for two years before the band imploded. After that I became a programmer. So maybe I'm more an ex rockstar programmer.

    I do have to say, the girls were more numerous when I was a rockstar.[/quote]

    Pleased to meet you :)
  • Aaron Digulla 2009-02-19 11:39
    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.
    That is because you do it in the wrong place: The correct place to define how the UI and the DB should look is between them: in the model.

    Enthought Traits has built a system on top of Python which allows you to create complex models which have a nice UI within a very short time because they keep all the stuff in one place (and having a nice syntax for this helps, too).

    So instead of defining a DB model and a UI and then trying to match the two, you say:

    class Employee(HasTraits): name = Str()

    and if you need any validators or special stuff, you pass that as arguments to Str() where the UI and the DB layer will pick it up.
  • Roman 2009-02-19 12:05
    Oh, man! This is SO me.
    I am The Developer of The Boring Software.
    :-(
  • Phil 2009-02-19 14:00
    I disagree with "Learn Off The Job". Programmers, unlike people in any other profession, have to continue learning throughout their career at the same rate as they had to learn at the beginning of their career. Sure, doctors are supposed to keep up with journals, but anatomy doesn't change.
  • Kermos 2009-02-19 16:41
    Phil:
    I disagree with "Learn Off The Job". Programmers, unlike people in any other profession, have to continue learning throughout their career at the same rate as they had to learn at the beginning of their career. Sure, doctors are supposed to keep up with journals, but anatomy doesn't change.


    Yes it does, it's called evolution!

    Of course...I suppose no doctor has to worry about that within their lifetime. ;)
  • Peter 2009-02-19 16:48
    > Michael A. Jackson said in his 1975 Principals of Program Design,

    That's not the title. Typing impaired by a shiny glove?
  • Eternal Density 2009-02-19 19:15
    This is why I'm glad my job title is "Hydrological Software Developer". Even though I have NO background in hydrology, the stuff I work on is far more interesting than Information Systems.
  • Francois C 2009-02-20 12:31
    It took me 2 days to figure out what's missing in this point of view.

    So yes, it is true that writting fancy code instead of straight foward code is done partly to challenge ourself while billing, ultimately, the end user.

    Yes, at fisrt glance, coding multi layered apps embrasing the latest techs and philosophies when all the end user wants is record simple data and reteive it later is a bit cheating, the same way the guy at the garage cheats on us when we bring our car. But I felt deep inside me it was OK anyway, and I just needed to find out why, and then stop feeling guilty. And I found out.

    There is a limited "supply" of good programmers, and therefor, programming ought not to sucks, or at least not always, cause if it always did, well, we would all leave the boat and the end user will be thrown back to the sixties (not that it would harm much, but that's not what he wants anyway). Even "Sexy" apps, reserved for lucky and gifted programmers, are based or dependant of boring apps, and boring apps developper have to make their job sexy in order to maintain the whole system.
  • mgbastard 2009-02-20 21:52
    I agree with everything here except that any of it sucks. It is a joy to write clean and well structured software that solves mundane problems. That joy comes from the satisfaction intrinsic in doing a good job. Being professional doesn't suck at all. Being professional is the most fun of all.


    That all being said: The satisfaction can also come by mentoring other developers.

    That and having good hobbies. None of that sucks.

    Most of all, bringing home your share of the family income from being professional; making love with your successful wife and having an explosive mutual orgasm with the happiness of your mutual satisfaction. That helps a lot.

    Sometimes your lucky enough to code creepware* though. That's always fun! Ok it's challenging. It does leave you a bit questionable in the ethics department. Hmm information systems at least lets you sleep at night. How would developing targeting software for missile systems leave you?

    *Creepware: Software that gives you the willies due to its impact on user privacy and the ability of the software or administrator to manipulate the user's social behaviors. Such as software that profiles users to each other (and to content, and to ADVERTISING) but NOT for the purpose of dating...
  • HallsVaporAction 2009-02-21 09:18
    Doucher
  • minini 2009-02-23 06:29
    Maybe I should be glad that I work in a company where NIH rules the world. Libraries that come with the language? pah! They could maybe not be supported at another system (we only use one kind of hardware) or not work properly with another vendors language implementation (we only ever use one vendor)! But at least, it leaves me the freedom of implementing and learning my own super-uber-hyper-hashtable, I just need to tell that I need a certain feature thats not yet in the inhouse library. A week more to the project? no problem then. And why not add the feature to the inhouse library hashtable already? It was not invented by me, so I won't change it. It makes us happy. And sad.
  • Faded 2009-02-23 21:02
    This is a wonderful article. It makes a lot of good points. I have degree is in architecture, as in building buildings type of architecture. I am self taught in Cold Fusion but have had the pleasure of having some very good, smart programmers work for me. They were smart, analytical and loved to try out new things. They were an absolute blast to work with. I learned a lot from them.

    I also learned that everyone single one of them had an almost compulsive drive towards complexity. Much of my time was spent listening to their suggestions for "improvements" and then asking why them why this was an "improvement." The answer I always got back was a variation on, this is a neat new technology that does cool stuff. Then I would say where is the business case that makes the business money. They would have no answer.

    On the other hand you need to keep looking at what is going on in the world. You need to stay tuned into the flow of ideas so that you will stay stimulated and not get board. Keeping up with the new ideas also teaches you that most new software ideas are really old ideas that have been recycled and had a layer of complexity added to them.

    Keeping it simple does fly in the face of all the marketing going on. Adding new features is a way to distinguish your product from other products. This creates a large force towards increased compelxity.
  • Simmo 2009-02-23 21:26
    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.


    ... let alone that hot chick in Database Engineering
  • Shakje 2009-02-24 12:39
    The problem with the article as I see it, is that it's been designed for flame-bait. On the one hand you have a very sensible and useful thing to say: don't write over-complex code when it's not needed, but on the other hand you illustrate it with an out-of-context example that doesn't really seem logical. You might be better using a small example design instead of the code. Currently, everyone who reads the article properly thinks it makes sense and ignores the example, everyone who writes unmaintainable code with hard-coded values sees the example and goes "hey that's what I do, I must write good code!" but everyone who skims the article and notices the example and isn't keen on hard-coding values, or sees problems with it in the future (especially if it would lead to problems in their own language) will assume the article is stupid.

    It's always more desirable to write code in a maintainable fashion, with the very rare exception where you know that the thing you're writing will never have to be seen by someone else, and does one function. Even if you're under duress to get somethung out the door, writing good code will doubtless cut down on costs further down the line.

    I've recently come across both overcomplex code (about 5 levels of abstraction for everything) which was a result of no real design, and oversimplistic, unmaintainable code (think huge global functions in the same files as huge classes, no scoping of variables, huge switch statements, etc.) which was a result of bad interpretation of the design. We have fixed huge chunks of the overcomplex code over the course of about 2 or 3 months, however, one bug was in the unmaintainable code which took a year to track down.

    The reality of the article is that it's about maintainability and not really complex code. If you swing too far either way you're going to end up with huge problems, but in order to be a good coder you need to sit on the centre line, with enough complexity to allow easy extensibility or maintennance (eg taking out those hard coded values into a config) and on the other hand you need to keep things simple enough and not get carried away or you'll really feel it when something needs to be fixed.
  • Stephan 2009-02-25 00:37
    I agree! Programming boring applications really sucks! I really want to create an all singing all dancing framework to make my life easier, but at the end of the day, only the development team will know of this superior engine.

    Think of how much it would suck to create the worlds most powerful engine with uber high HP and excellent fuel economy, and not be able to share your stats. Even worst, designing the most beautiful car and only your employer will ever see it, and then he complains of it being too flashy and too many features... That's corporate programming for you!

    I am a Software Developer(cool title to make us feel wanted) creating web based applications for the life insurance sector. And it SUCKS! I am starting to freelance and by the end of this year(hopefully) freelance permanently. At least then I can choose what type of project to do...
  • Stephan 2009-02-25 00:45
    Simmo:
    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.


    ... let alone that hot chick in Database Engineering


    You have a chick in DB Eng!!! WTF! I hate you! All I have is internet with pron! At least you can look at something breathing! :D
  • James Taylor 2009-02-25 11:38
    Alex
    Thanks for the link - it generated a ton of interest and some fairly "pithy" comments. I have been writing some responses:
    Business Rules to Programmers: Methink thou doest protest too much I and II. Tomorrow I will post specific comments about the comments I received.
    Enjoyed the debate
    JT

    Main Blog: JT on EDM
  • Dave 2009-02-25 11:42
    I couldn't agree more with this article. I too have fallen victim to the "it's new, therefore it's cool, therefore we MUST use it!!!" syndrome. The end result was that I created (to me at least) amazingly beautiful little pieces of systems but never really finished the job. Definitely did not maintain a reputation for getting effective work done quickly. I've gone back to boring, simple, quick code that gets the job done.
  • Meg 2009-02-25 14:31
    Are you for real? No wonder no women want to work in your dep't! We aren't there to be porn stars to your "rock stars", we're there to work and get paid for said work. Y'know, like you should be doing instead of looking at porn. FFS.
  • nuttycom 2009-02-25 16:51
    #3 seems counterproductive to me. It has often been my experience that at the beginning of a project, I simply didn't know enough about some technology to be able to deliver on the requirements *without* learning to use new tools and techniques. I regard the ability to learn new things while working on production code to be the most valuable ability a programmer can have - things change so fast these days that unless you're building a system from the ground up, integration with other systems will necessitate learning some technology that you didn't know before the start of the project.

    I write code for work, and I write code for fun, but I'm not going to go out and create a personal project that's oriented around learning the things I need to know to perform my job - if what I learn on my personal projects is applicable to work, that's great, but I don't expect it to be. Pushing learning (about tech needed for the job) into off-the-job time is doing nothing more than extending one's work hours.
  • An FMDev 2009-02-25 21:12
    damnum, that was a good one ;-)

    // damnum captchas
  • Eric Pearson 2009-02-26 13:50
    And that's why some of us move to management.

    Eric

  • Death 2009-02-27 07:25
    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.


    But that nerdy but still but hittable girl two cubicles down might.
  • Aaron 2009-02-27 12:03
    JT has written a response to this article:

    http://jtonedm.com/2009/02/27/business-rules-to-programmers-methink-thou-doest-protest-too-much-i/

  • David Wright 2009-02-27 15:10
    In the beginning, there were no databases, just files, possibly of punch-cards, and it was called Data Processing (DP). A program ran, used an input file or two and produced output files, some reports, maybe paper artifacts like cheques or invoices.

    Most of the code as assembler at worst, or COBOL at best (those of us using PL/1 felt special).

    Then came hierarchical DBMS and 4GLs so, as noted elsewhere, non-programmers could extract data and write reports, followed by Data Warehouses and cubes and what-ifs; so anyone coding a report these days should be beyond boredom and approaching calcification.

    The thing is, there have been successive waves of new languages and tools over the past 50 years. I joined the wave during the hey-day of 3GLs, but with some systems still running using assembler emulators (ah, the emulator, it will always be with us). Assembler programmers looked down on COBOL coders as not really programming.

    My first programming used a file management system built in-house at my insurance company employer. Now we have relational DBMS.

    Some of that programming was writing reports. The worst was when a business guy used me like a human prototyper, told me what he wanted, I would come back in a week with a great report, he would look at the results and then tell me to change it to do something else. I thought I was done and had done a good job, and didn't like being told to change my good work; he was just doing what-ifs and improving his results based one what he got. ... so I was thrilled to be part of implemeting informational data environments that business people could now do reporting from.

    This is just one example of programming that had to be done manually to start, but once it was found that thousands (millions?) of programmers were doing the same thing, a bright person somewhere created something to do it easily or automatically.

    There have been succesive waves of this automation of programming. There was also a parallel automation of common domains; I am sure it has been decades since any non-software company wrote its own GL system.

    These parallel paths collided in the 90's. CASE tools came along that could generate code, all the code for an information system. Don't scoff, the best tools worked. However, IBM killed the market with AD-Cycle and the big ERP packages came along at the same time and killed most in-house development of any kind.

    The thing is, we need these things to happen, or we were going to run out of programmers. Back in the days when operators still manually connected phone calls, it was projected that entire female population of the USA would be needed as phone operators if phone use continued to grow as expected (sexist, I know, but of its time). This is the case with programming; we need new tools and automation to take over the boring stuff so talented programmers can take on the next set of problems that can't be automated, at least not yet.

    The latest tools to take away boring stuff are BPM process tools, and Business Rule Engines. Waht is the most boring programming in the universe? Maintenance of existing systems. Let's say in your example that a rule needs another state added to it. If the rule is in code, it has to wait for programming resources and a system release. If the rule is a Rules Engine, the business changes the rule itself, tests it and then puts it in production; no coding needed. That is not pixie dust or over-blown expert systems, that is real technology in use now. When you apply for credit today, do you think all the rules and calcs to get your credit score are hard-coded? Not a chance.

    So, if programmers out there want to keep doing the "same old, same old" instead of letting technology do the boring stuff, that's fine. The rest of use will be doing the non-boring stuff.
  • Gabriel G 2009-03-06 22:11
    I do agree with you statements. I worked for years doing business software, now I work doing development on a big CAD application, and yes, you cannot compare one with the other.

    In my years as a business developer I´ve found there are some excuses used to avoid the boredom of doing business software:

    One is rewriting the systems every couple of years with a new technology/language (which is, in most cases, a lame excuse to do some fun work). In the CAD app we have some source code that was written in 1988. And lots of code that is more than 10 years old. And a rewrite never crosses our minds!

    The other is in-house framework development. In the degenerate case you get a custom application framework for every application the company has. Then again, developing a framework is fun, developing a data-form is not.


  • Underemployed coding guy 2009-03-08 08:53
    Having the business dictate how software should be written sounds about as sensible as me telling my surgeon where to cut.

    At the end of the day it's just an HR issue, some teams of programmers will work well together no matter how clever or not the code is.
  • SnapShot 2009-03-10 14:06
    Or, as Donald Knuth said, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
  • Miklos Hollender 2009-03-12 10:11
    I have to disagree with the basic premises of the article.

    "Whether you’re using Visual Basic 3.0 or XHTML, the concepts are pretty much the same: the database needs to be exposed to the user in user-friendly terms. The code required to do this is, and always has been, fairly tedious:"

    Why on Sweet Earth would you write a CRUD application in a general-purpose, textfile-based programming language? Why not a framework that's exactly for this purpose?

    I'm writing my code in Microsoft Dynamics-NAV (or if you want something Open Source, check out OpenERP, similar) and I don't have to write any code to link a db field to a form, I just set the SourceTable property of the form designer to the table and drag out the fields in the Field Menu.

    If later on the users say the field should be mandatory then I just put 1 line, TESTFIELD("Field X"); into some appropriate trigger. This is a good example how a high-level CRUD application environment works:

    - it knows what the default values for fields are: 0 for decimals, '' for text etc.
    - it checks if the field is not the default value
    - throws up a message box informing the user
    - stops everything
    - rolls back the current transaction

    all in 1 built-in command.

    That's how you build CRUD systems. Not hand-coding everything...

    I always wanted to write about this here because there are so many examples of these amazingly low-level approaches to CRUD systems in many examples here that it's amazing... it's a huge waste of money.

    Not wanting to pay a lot for Dynamics-NAV? What about Visual FoxPro then? Or high-level free Open Source frameworks: http://dabodev.com/ etc. etc.

    Hand-coding CRUD is extremely silly.
  • AP 2009-03-19 15:11
    This is where I think you don't understand the article. He is not saying that software is ever boring for him. He says - don't make the problem more complex than it needs to be, just to make it interesting. Solve the real problem you are being paid to solve, with the right combination of practical need and theoretical best practices - be professional.

    You can certainly find tons of fun and satisfaction in solving all kind of problems in code, like you state (and I completely agree with that), but that's not what the article is about.
  • hashim 2009-04-08 17:10
    even your article is boring.
  • Robert666 2009-05-19 08:56
    >> A UI generated from the database is just as bad as the database that’s generated from the UI.

    Absolutely not. Generating the UI from the schema (which includes all of the catalog, i.e. constraints) is the only way to enforce 'one fact, one place, one time', or as the OO folk call it 'don't repeat yourself'. Don't repeat.

    The argument is that database (relational) schemas are too often un-normalized, and therefore can't be complete with regard to constraints, i.e. some constraints are 'too complicated' for the database. Wrong. The data is what persists. Since 2000, how many languages du jour have there been? How many frameworks for web development? The SQL (not really relational, but close enough for government work) database allows data to persist across databases and time. I know, folks complain that each vendor's SQL is different. And at the margins, yes. But no one said you need to schema at the margins. Your argument to KISS applies to using SQL, too.

    Beyond that, there are programs like SwisSql, which are able to translate most SQL across databases, if one needs to.

    A normalized database's purpose is to generate new data from existing data; that's the whole point. Constructing input screens from the schema drives the screens to be data logical. In doing so, designers and users find where the potholes are. That is a good thing. Or put another way: if you CAN'T generate a useful UI from your catalog, your data model is screwed. Think about that for a second. Go back to your premise of tedium and repellence of complexity. How the UI LOOKS is separate and apart from the data being displayed. Whether it's a list box or radio set or foobar is programmable. Whether an input field is dependent on some other data for validation is in the catalog. If it isn't, your database is screwed.

    And so on.
  • John Cowan 2009-05-19 10:17
    The essence of a profession, as distinct from a job, is that a professional is answerable to two masters: his client and his peers, and has to balance off their demands. Those peers set up all sorts of rules that professionals have to abide by. A doctor that cut off a patient's leg just because the patient asked him to would have trouble, and still more a lawyer that helps his client cheat on his taxes (as opposed to helping him find the best legal way to reduce them).

    That said, I don't know if programming (I am old-school, and disdain such inflated expressions as "software engineering") is a profession or not.
  • Some Dude 2009-06-23 18:24
    Excellent. Well, here's a list of realizations that complement your article.

    First, programming is work, it's laying and connecting pipe. It's not clever. It's not glamorous. Any satisfaction you get from doing it is the satisfaction of having gotten something done, and not because you're somehow special for having done it. There's no Zen to it, unless it's in the acknowledgment that all is work and all is boring. Don't take the intimidation people feel who don't understand it to mean it requires intelligence or that you're special. Stop trying too hard. Nobody's impressed. Nobody's paying attention. And if they are, it's probably because you look funny or you have broccoli in your teeth.

    Second, programming is organization, and most of the time, trivial organization. Put stuff here, put stuff there, move some stuff around. Tada, there you go. Sometimes it feels like cleaning your bathroom, or organizing your bookshelf.

    Third, reasoning is just a mechanical process. It's not magical, it's not particularly fascinating, per se. It's completely described by the syllogism. What do you think proofs are? They're descriptions of how you reasoned from A to B. Computers can do it. What they fail in is conception and judgment.

    Fourth, people who fail to acknowledge this reality about programming, while they believe they are themselves somehow super smart, are probably people who lack creativity, intelligence and imagination, or are somehow short-sighted, much like a dog running after a chew toy with the same enthusiasm day in and day out. Maybe you are dumb. The least you could do is be honest and quit being a geek. You also probably lack social skills, and no amount of rapture is going to save you from the self-inflicted and boring cookie-cutter life you're leading and will continue to lead. There's nothing more irritating than listening to some guy who's so caught up in his own trivial self like some adolescent turd. Nobody cares if you wrote some "killer app" or that you know some terminology. Again, no one is impressed, and you're not special.

    Fifth, look at the big picture. Getting lost in irrelevant details not only makes you look stupid, it makes you stupid. It also causes your balls to shrink. This applies to any fixation that provides you with a faulty sense of self-worth. Programming is a trade. People need code to do other things. You write it.

    Sixth, "the zone" is not a moment of supreme intelligence and insight. No. It's a moment when your brain shuts off enough that it stops protesting and thinking about more interesting things (like sex) and allows you to focus on doing something boring like moving code around in an editor. Personally, I find it a relaxing activity. Short cuts to "the zone" include alcohol and weed.

    Seventh, all code sucks. And as this article states, the more clever you try to be, the more you try to compensate for a small wiener or keep yourself from the realization that coding is a chore, the worse the code is. Get over your code ego.

    In summary, good programmers acknowledge that there is no magic to programming. They just have the self-discipline to work through the problem and don't feel the need to prove themselves to anybody. They aren't looking for something in the act of programming which isn't there, like some Don Quixote with Down's. Nobody cares about you. They care about the product. Throw away all the bullshit life lessons they taught you at school or you heard from Big Bird or Oprah. Life is not a maniacal high on ecstasy. It an anticlimactic journey which always ends in death and where clamoring for more than just existing is just a waste of energy. That, and you'll end up irritating everyone around you and looking really awkward. Stop it or we will ignore you.

    To mangle a quote from Edison, programming is 99% perspiration and 1% not being a dumbass and getting back to perspiring.
  • Mahesh 2009-07-13 05:40
    Couldn't agree more..sob sob
  • 101010 2009-07-13 15:10
    she might if you aren't a dork. just don't talk too much about your l33t programming skills.
  • LongTimeNerd 2009-08-23 11:41
    This sort of interplays with your Jocks vs Nerds. The reason nerds love programming is because they learn from the time they were small that having no looks, no social skills, and so no ability to get laid, never mind control the random chaos of existence in society, programming gives them serious relief as they are in total control of their environment. Its predictable and can even, apparently, be sexy, although I think its somewhat vicarious.

    Being long in the tooth, I truly enjoy the fact that hi tech nerds have replaced doctors and lawyers as the targets of attention in bars. Money still talks.
  • Iain Collins 2009-09-17 06:27
    max:

    Don't write articles like this. You've just told us that:

    1) You don't have any experience in modern, agile development.
    <snip!>


    Because environments that are not more-agile-than-thou are old fashioned and are therefore inferior?

    You know I think you just might be the target audience for this article...
  • Iain Collins 2009-09-17 06:53
    Miklos Hollender:

    I don't disagree with this article but I do take your point. However I think you are thinking of the types of cases you work with but perhaps neglecting other environments which call for different approaches.

    Personally, I find that most systems I work on is either so simple enterprise abstraction packages only makes it more complex and using a nice generic (abstracting) SQL interface library is more sensible, or so complex and ad-hoc none of the off the shelf solutions would do (at least without either being far too slow or again or adding horrible complexity and slowing down development).

    I would argue in practice is more common that not, and that is what Alex is driving at, but your right in that it can be much simpler and there are lots of even very cheap solutions to do just this kind of abstraction in particular for .NET and Java (but would note in some scripting languages it's so easy this sort of thing is redundant anyway).

    I do fully appreciate there are many types of app development where they completely rock and make perfect sense. I think it comes down to application type and business environment as to what makes the most sense, in some environments (by which I mean both technical and commercial) it actually makes less sense.

    As a general rule, I think developers from different environments often misunderstand each other because they are trying to apply their own hammers to others nails (and I'm not excluding myself from that). It's easy to think some other guys are "doing it wrong" because they are doing something in a way we personally dislike and would never want to be apart of (for perfectly good reasons) but that doesn't mean it's wrong for them.

  • Mitch 2009-11-08 09:37
    Freakin' awesome article. I'm not even a programmer and I thought it was sweet. Thanks for the nice read.
  • alwin 2010-01-15 17:56
    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.


    Yeah, you're right, it's bad. Adding a sql database, tables to contain the data, writing db connection classes, and a settings object which should be updated if the data is updated in the db via a trigger should make everything a lot easier.

    I'll pick "bad" compact code over complex fragmented code any day.

  • LED display 2010-02-09 04:13
    <A HREF="http://www.ledtv.asia">LED display</A>
    <A HREF="http://www.ledtv.asia">LED Signs</A>
    <A HREF="http://www.ledtv.asia">LED Message display</A>
    <A HREF="http://www.ledtv.asia">LED Message Signs</A>
    <A HREF="http://www.ledtv.asia">LED board</A>
    <A HREF="http://www.ledtv.asia">LED curtain display</A>
    <A HREF="http://www.ledtv.asia">LED Soft curtain</A>
    <A HREF="http://www.ledtv.asia">LED soft display</A>
    <A HREF="http://www.ledsigns.cn">LED display</A>
    <A HREF="http://www.ledsigns.cn">LED Signs</A>
    <A HREF="http://www.ledsigns.cn">LED message display</A>
    <A HREF="http://www.ledsigns.cn">LED outdoor display</A>
    <A HREF="http://www.ledsigns.cn">LED fullcolor display</A>
    <A HREF="http://www.ledsigns.cn">LED board</A>
    <A HREF="http://www.ledsigns.cn">LED message signs</A>
    <A HREF="http://www.ledsigns.cn">LED panel</A>
  • Dom_ 2010-02-12 16:39
    I remember reading the article the day it got posted almost a year ago and I was thinking, man is this guy right or what!?

    I was clearly in a situation where the drive and spark of the project and its team members had long run out and the grind had begun. It really made me re think my whole situation and I decided that I was not going to work like that. A year later I have joined a crack team of developers who put great honour in the software we deliver and we pride ourselves on being up to date on most current technologies, viable for line of business applications of course. And there really is a market for up 2 date new kids on the block out there.

    My problem at my previous engagement was that thejoy of knowledge and exploration were non-existing with my colleagues. I guess they had settled in life or something. I had not.

    I guess what I'm trying to say is that your dayjob don't have to suck, even if you're a programmer! If you're knowledgeable and brilliant there are plenty of companies waiting to hire you. Remember they should be glad you decide to work for them, not the other way around.

    I'm forward to some more life-changing articles Alex, thanks for the inspiration this article gave me.
  • Matthias 2010-02-25 18:40
    You don't know what you want !
    On one hand that's hard, but on the other hand, that's too easy... That's YOU is sucking.

    Program in Delphi, so !
    Or C++...

    Programming is USEFUL (but boring and annoying... I admite...) But without this, NO programming means NO programs an NO OS... So no computer science!
  • Neil 2010-04-05 19:03
    That is why I liked games programming (no specs, no documentation, no other programmers to mess up the code). Each game was a different set of challenges, puzzle game, 3d isometric fighting game, vertical scrolling shoot 'em up, flight simulator, racing game and a 16 week development schedule for 100% assembly language game :)

    I've also had to write custom software to convert 68000 assembly language to C++ which was a whole different set of problems.
  • Nightfly 2010-05-17 03:47
    Amen.
  • dhouse109 2010-05-24 12:00
    A few years ago, a friend of mine suggested that User Experience was the new "sexy" tech position. At the time, I thought she was confused...UX didn't seem like a real tech position to me. After a couple years of study however, I found myself arriving at the same conclusion. UX is "sexy" because it's all about design and engineering and less about programming for the sake of programming. It's like stepping into the shoes of Leonardo da Vinci and coming up with amazing things to create. The programming part is just the act of making UX.
  • BushIdo 2010-05-25 19:35
    The "balancing the extremes" is exactly why general advice articles are often not very useful.

    You use one userdefine variable, do some UI to make it really nicely accessable and all - and no one ever needs to change ist.

    You hardecode exactly to specs and just when you are finshed the boss demands this little extra, which doesn't fit at all in the model you devised.
  • James 2010-07-10 19:57
    So true. And actually, a big reason programming often gets tedious is because people lose sight of keeping things straightforward. How many times do people code themselves into messes trying to make things "simple" (simple in the wrong way) and end up having to do tedious debugging to get their own monster to work. It's the whole "complex vs. complicated" thing. Small and smart is nice for a moment while everything is in your head, then becomes a cloudy box you have to strain to look into. I'd rather look into a big clear box that I can understand instantly.

    That's why I think it's silly when people talk about the verbosity of some languages (particularly Java) and say that makes writing code in those languages take longer, as if typing is all there is to programming. By that logic, the best speed chess player in the world would be the person with the fastest hands. This is not to say Java is a more productive language than others, I actually prefer Python, but not because it's faster to type, because it's faster to read.
  • Felix 2010-10-02 11:37
    Although you sure ARE making some points, I think it's a little bit simplified.

    Of course, as a coder, you should most of the time focus on the business needs and nothing else, but what are those business needs? I know enough "legacy apps" that perfectly match the business needs that were identified and specified back then (last year), but are practically unmaintainable when it comes to changing even the simplest things...

    So, I think it IS crucial for a good developer to at least reflect the business needs himself, understand possible future changes early, talk to the customer about that, maybe explain some technical issues. And more often than not, this will lead to some software design beyond "if (a) then (b) fi" ...

    If you don't do anything more than creating code for the business needs that have been specified -- you are just that: a coder. Better try to be a developer :)

    And no, I'm NOT advocating horrible over-engineering, I just want to make clear that SOME engineering is needed most of the time, and it should start with understanding the business needs and examining that for "forseeable" future changes.
  • cindy 2010-12-16 02:47
    find for all kinds of amazing watches and women handbags

    http://replica038.com/
  • Ted 2010-12-26 04:06
    Frustrated:
    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


    Yeah, but according to Alex's logic, that is what you want: focus on the business rules and let FileMaker handle everything else.

    And, off topic, I have seen some exciting stuff built in FileMaker.
    http://innerfile.com/services/filemaker/consulting/
  • The great Nick 2011-06-07 14:42
    Learn Off The Job, no i disagree it is the responsibility to offer you as much training as you need to do your job. When you train at home you are basically working unpaid. And I have a policy of no free work under no condition what so ever and it has served me well.
  • someone 2011-07-23 21:07
    The best programmers ARE the ones who create the most beautifully-elegant, exceedingly-innovative code, AND the ones who can deliver software before deadlines, and under budget.
  • someone 2011-07-23 21:18
    Junior developers enjoy introducing an unnecessary complexity such as any-cool-library-floating-around simply to learn how to use it. Senior developers enjoy working less and getting more done, which means they don't enjoy adding any unnecessary complexity. It's hard to be a team when someone too senior has to work with someone too junior. :) I'd vote for senior-only companies.
  • tharpa 2011-10-04 14:52
    Sucks:
    This article sucks.

    Good job. You've highlighted the problem and then said "Suck it up and act like the tool you are."

    Way to think inside the box, Alex.


    The majority of the time, thinking inside the box is the way to go.
  • Watson 2012-05-05 07:17
    Alan M. Turing:
    Instruction tables will have to be made up by mathematicians with computing experience and perhaps a certain puzzle solving ability. There will probably be a great deal of work of this kind to be done, for every known process has got to be translated into instruction table form at some stage. … This process of constructing instruction tables should be very fascinating. There need be no real danger of it ever becoming a drudge, for any processes that are quite mechanical may be turned over to the machine itself.
  • Andrew Gibson 2012-06-16 17:06
    I would like to add my voice to the "if you aren't having a great time, you're doing it wrong contingent." Boring software is dangerous.
  • Andrey 2012-10-26 06:08
    I understand your point, but imagine how boring other professions(except several) are (or at least seem to be)...
  • Rohit 2012-12-23 04:40
    If you find it boring - at work and at a hobby, do something else! I was a software developer for 7 years writing banking software. I tried very hard to cultivate a passion for it, by coding at home etc, but I just couldn't. So I quit and became a math and sports teacher, which I find much more enjoyable.

    Programming can be fun, but I guess it depends on the individual. I know lots of folk at my old place of work who love their job and are very passionate about it. I just couldn't do it!

    christmas++!!
  • DOKKA 2013-04-06 18:59

    Another important fact is that most programmers aren't even professional. they don't know enough of the language to even do things properly. This is the current reason why I hate the field. It's as if you play the janitor and the architect, and doing both is insanity.
  • ayeeee 2013-11-14 17:20
    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.
  • jonny 2014-10-07 21:11
    you find that boring?

    try going the whole day passing parameters to dull functions and making unberably long associations to arrays for god knows why?

    I talking abou ERP software, how those are boring