- 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
or:
ant build deploy
or:
./custom_build_and_deployscript.sh
that was hard wasn't it?
Admin
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.
Admin
thanks for the informative article.
Admin
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.
Admin
"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.
Admin
"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???
Admin
Admin
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 :-)
Admin
Man those words ring true for me... Couldn't agree more.
You are lucky, btw... I wish I was only working 40 hrs/wk...
Admin
Amen!!
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
"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.
Admin
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.
Admin
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.
Admin
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.
Admin
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!
Admin
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.
Admin
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!
Admin
Admin
Hey, there's better name for 'boring' software that you mentioned. Enterprise software. Better right?
Admin
Admin
Admin
“any damn fool can write code that a computer can understand, the trick is to write code that humans can understand” - Martin Fowler
Admin
yeah, this will get printed and hung on my cube wall
Admin
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.
Admin
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.
Admin
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!
Admin
Nobody gets paid to write the "sexy" popular stuff, because it's all open-source.
Admin
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
Admin
I remember reading some Garfield comic that says something like: "Work is so bad that they have to pay you to do it"
Admin
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.
Admin
No, I don't agree
Admin
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.
Admin
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.
Admin
Admin
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.
Admin
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.
Admin
Actually, she did!
Admin
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.
Admin
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.
Admin
Dude, use rails. No more stupid validations.
Admin
Brilliant!
I especially like the part about aspect-oriented approach!
Admin
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!
Admin
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.
Admin
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/
Admin
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 :)
Admin
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.