- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
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.
Admin
Admin
Admin
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.
Admin
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.
Admin
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.
Admin
Admin
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.
Admin
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.
Admin
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?
Admin
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.
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.
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.
Admin
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.
Admin
And if you have a UI generated from the database, and a database generated from the UI, you end up with Filemaker
Admin
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!
Admin
I like how they censor your comments here just because you say the article was boring and tedious, which, IMHO it still was.
Admin
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 ....
Admin
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?"
Admin
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.
Admin
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.
Admin
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.
Admin
I like how unregistered users always accuse people of censoring, when it's very rarely done here for any reason.
Admin
What an incredibly boring, tedious, and unsexy WTF article that was.
Admin
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.
Admin
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.
Admin
Ouch...that just hurts. ;-)
Admin
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.
Admin
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.
Admin
ha ha, I program video games for a living
Admin
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
Admin
Blimey.
Admin
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
Admin
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.
Admin
Nurses are wanted, I hear. Gives a different kind of satisfaction.
Admin
Agreed. I hate the term "rock star" programmer. If such a thing exists, I've never met him (or her).
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?
Admin
Admin
Good article by Alex and really good comment by Mr. Chow.
Admin
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.
Admin
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.
Admin
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...
Admin
Games dev hasn't been exciting since the early 90s.
Admin
Admin
Code should be as simple as possible, but not simpler. I think that summarises the article as simply as possible.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
What are the boring bits of programming?
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.
Admin
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.