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

    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.

  • (cs)

    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 (unregistered)

    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 (unregistered)

    Open source development in your free time is a nice way to counter-balance tedium.

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

    I must admit that I do get a thrill when I finally figured out what was causing the code to break.

  • (cs) in reply to DaveK
    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.

  • (cs) in reply to Dirge
    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 (unregistered) in reply to AC
    AC:
    What's with all the hard coded values in the example of what code *should*?? look like?

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

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

    Not a good example for the young'uns.

    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 (unregistered)

    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 (unregistered)

    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!

  • (cs)

    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 (unregistered) in reply to DaveK
    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...

  • (cs) in reply to Lego
    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.

  • (cs) in reply to Richard
    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 (unregistered)

    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 (unregistered)

    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 (unregistered)
    1. 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.

  • (cs) in reply to Jon
    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.

  • (cs) in reply to Anonymouse
    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 (unregistered)

    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?

  • (cs) in reply to dxmio
    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 (unregistered) in reply to Dirge
    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.

  • (cs) in reply to savar

    [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 (unregistered) in reply to EvaUnit02
    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 (unregistered) in reply to Alex Papadimoulis
    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 (unregistered) in reply to hatterson
    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 (unregistered) in reply to Starbuck

    As my ex is a perfect example of, sometimes they do.

  • (cs) in reply to Joe
    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 (unregistered) in reply to imalc
    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 (unregistered)

    I actually read almost 1/3 of the article... uff...

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

    That's okay. I want the hot chick in Accounting.

  • Franz Kafka (unregistered) in reply to D.K.
    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.

  • (cs) in reply to AndyL
    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 (unregistered) in reply to Leo
    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.

  • (cs) in reply to bohica61
    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 (unregistered)

    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.

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

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

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

    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 (unregistered)

    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?

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

    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.

  • (cs) in reply to Mark
    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 (unregistered)

    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 (unregistered) in reply to imalc
    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 (unregistered)

    Are you serious, grandpa? Should we get off your lawn, as well?

  • (cs) in reply to Mr A
    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 (unregistered) in reply to jasmine2501
    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.

  • (cs)

    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 (unregistered) in reply to jasmine2501
    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.

  • (cs)

    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.

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

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article