- 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
it's not the fact that it's hard. It's a bad process. In the real world a build requires validation from SQA and other departments. I record in the db typically does not.
Admin
You are mistaken. Assload is the metric measure, fuckton is imperial. To, it's 1327 craptons in a fuckton, but 1000 buttloads in an assload.
Admin
I think the name "Steve Jobs" has significant relevance here.
Admin
Well, sometime it's like sitting at the dentist. But that's part of a job, I think...
Admin
I think of them as seperate attributes. Substitutional or Transformative can be Boring or Sexy.
You can use sexy (esoteric, bleeding edge, whatever) techniques to create substitutive code...we see that every day in fact and we all agree it is bad. Why? What makes it bad? My answer: The "good" of substitution is that high-potential humans aren't doing as many mindless tasks (the other goods, greater efficiency and lower cost, are derived). In other words, it displaces workers from automatable jobs or frees them to do more important things, depending on your perspective. Sexy means longer development and higher maintenance and that means a lower net gain (less good) from the substitution because development time weighs against use time.
How about transformative code? You can use boring techniques to create a transformative program. However, transformative code is more likely to extend the art. It is more likely to require at-the-time esoteric techniques just to solve the problems it creates. Creating Transformative software is less software engineering and more computer science. Science is sexier than engineering -- believe it or not. So you cannot instantly condemn the use of sexy techniques when writing transformative code. Instead, you let the market sort it out. If a transformative program succeeds in transforming what humans do the developer clearly chose the right mix of boring and sexy for the time.
As for agreement, I guess my problem with the article is this: IMO Programmers who get bored writing substitutive code should, rather than accepting their fate, look for transformative projects where their creativity and problem solving abilities will be challenged. Most shouldn't do it full time any more than most musicians should quit their day jobs, but the challenge will improve their skills and perhaps reduce their frustration at having yet another business needs discussion.
If the right solution is to buck up, accept the boredom, and do, why don't we extend that to the people whose business flow we are improving? Why don't we just tell the factory workers to keep using hand tools, tell businesses to keep manually calculating every bill and writing reciepts out longhand? Not efficient? Just lower the pay of the workers and tell them to work longer hours. Heck, people in our government have actually used the term "mandatory volunteering" recently... that sounds like a solution we can all embrace to force workers to volunteer to work weekends at no extra pay. Of course we have that pesky 13th amendment, but we can do to it what we did to the 18th. We can improve the business bottom line without writing a line of code...so long as we are willing to accept the waste of human potential it entails.
Admin
thanks for this wonderful article.. i find myself a boring programmer in your words.. who is just so used to creating information systems with the tools that i have to use.. sometime they don't even work the way they are supposed to and crash many times..
but anyway this post actually got me thinking where to get satisfaction.. i graduated with Comp. Sci. degree but while developing information systems, got more interested in learning the business that i think is the place to go further in the career. i'm fed up with my programming career and want to move on to somewhere else and looks like i can do some transition from pure IT to IT/Business..
Admin
I couldn't agree less. While I think is a mistake to do complex code for the only purpose of having a challenge I do think that using patterns, good design architectures or AOP helps much more the business than you might think. The great majority of the cost of a system comes from maintainance and not from the development of it. In that sense, where I work we use all these things wisely creating simple, usefull and requirements based yet fun to develop software.
Maybe as we create transactional systems, social webs, and desktop applications maybe we are not the best example for this article but I strongly believe that using patterns, making code reusable by designing better, using AOP for example to define transactions and many other techniques that may be considered as ways to get challenge tend to make code much more maintainable and ends up with a better TCO for almost every software.
http://martin.zauber.com.ar/ http://blog.code.zauber.com.ar/
Admin
Nope, Alex is simply a depressed, cynical and uninspired java developer.
Sorry could not resist.
Don't let this destroy your attitude to software development.
Admin
Getting the job done is the bottom line, but you have to write maintainable code. Copy-pasting code because it's "easier" or "quicker" than factoring out common parts doesn't help the bottom line in the long run. "Rockstars" know when to do something quick and dirty, and when to invest in some "complexity" to save time in the future ...
Admin
Lol but shouldn't it then be buttlode and asslode? Are 1000 asslodes a shitlode? Where are my charts, hold on...
Admin
I agree on everything except for the part where you say bad stuff about programming ;o
Admin
-Harrow.
Admin
I'm on the exact same page and couldn't agree more. I decided to post just to tell you that you're not the only coder out there with this sentiment. When I first began my career I was a > 40 hours guy all the way. Now, after fifteen years in the industry, I find that I have enough "programming fun" at work to keep me content.
Admin
This could not have described myself better. It almost serves as an epiphany. I just did this recently by building this Smart Client/CAB app with a WCF server blah blah blah. KISS it is from now on. Thanks for the therapy session.
Admin
There's an important distinction between "this code is boring" and "I am bored coding it". Frankly, I think all code is boring to look at. It's what it does, the problems that it solves that are interesting.
I do not enjoy programming because writing code is exciting; I enjoy programming because solving problems is exciting. It doesn't even have to be a very interesting domain; it just has to be a problem that needs solving and that someone cares about having it solved.
I cannot disagree more about learning on the job. If you are not continually learning something and getting better at what you do, you are headed for burn-out. Humans are rarely satisfied with stagnation and mediocrity. You can almost always learn to do the job better, and you're not going to learn how to do your job at home. Home is for things that are Not Work (unless you are planning to burn out in the next five years).
If you are bored because you are coding the same tedious thing over and over, You Are Doing It Wrong. Why are you coding the same thing over and over? Why aren't you coding it once and calling it/c&p-ing it/subclassing it over and over?
Personally, I was inspired by "The Man Who Was Too Lazy Too Fail"; doing unnecessary extra work is stupid, and in coding, usually causes more maintenance headaches in the long run. I write code to make future maintenance easier, because either I will be doing the future maintenance, and making less work for me is good--or it will be maintained by some junior programmer with far less experience who will be calling me to ask how to fix it, which I Do Not Want to have to be bothered with in the middle of working on the next project.
Smart design--not 'clever' design, mind you--means designing ALL the code you write to require as little hassle as possible to change the obvious things someone is going to want to change later. It will be changed later, count on it. I learned the hard way decades ago to write even my one-off, personal test programs in a modular and maintainable way, because The Boss may come along and say "Hey, that looks really useful for our field technicians! Can you deploy it to them?"
There is, of course, a difference between smart programming and 'clever' programming. I think it's smart to have solid, bug-free, well-designed, maintainable code. I like Brian W. Kernighan's quote on the topic:
Admin
No, No, No!
When will you people get it?
Craptons and Fucktons are archaic imperial units that are confusing and not generally accepted.
Here's why.
12 Shitzes = 1 Crapton 3 Craptons = 1 Fuckton 126 Fuckton = 1 Ferfuksake and 24 Ferfuksakes = 1 Bush
The correct SI units for error is the Smear.
A decimal point out of place in a spreadsheet corresponds to about 1/8th of shitze or the simpler 24 milli-smears. Windows Fista is about a giga-smear.
Admin
I dunno where you got your conversions, but over here, we simplified a long time ago:
1 metric fuckton == 1000 'oh fucks'
Admin
If professional devs HATE that kind of code so much, give it to me - I'm a business type who has been frantically trying to find a place to write just that kind of 'dull' code. Why? Because I spend a lot of my time right now creating workarounds for garbage other people wrote in systems we can't touch. Using ACL to bridge two homegrown systems together, which are each so screwy, they can't talk to each other natively. Writing a complete asset reporting package in VBA (I wish I was kidding). I document business processes, write business logic and implement it because no one else did, and now the systems and data are a mess. MY entire job description could be 'read 'the Daily WTF' and then identify which of our clients are being written about there'.
Admin
I have been exactly where this guy is. But this is a bad place; the wrong place. You don't have to write a useless expert system but you can write the best damn system ever built. This doesn't mean writing your own operating system in assembler but it might mean coming up with an interface that is just plain genius, or pushing everything (if it applies) into web services and allowing dozens of previously stovepiped systems to integrate. Or best of all you might not simply replicate the crappy paper system but jump in with the users and figure out that they really need to store less data but they need to access it while on the road with some cool iPhone app. If you want to have fun AND be productive you have to think out side the box, man.
Admin
I'm pretty sure though that Michael A. Jackson did not mis-spell "principles" in the title of his book.
Admin
Mostly agree with your sentiments wholeheartedly, except for "That 10-year old “Classic ASP” code hasn’t gotten worn out, just much less fun to maintain".
Classic ASP IS worn out and isn't just less fun to maintain, it actually costs more to maintain than (well written...) code in newer technology.
Admin
Ok, if programming is boring, you are not doing it right :-)
A lot of the stuff that comes with the job is boring, though, such as filling in numerous spreadsheets or test reports or whatever.
I've found this quote from actor Edward G Robinson to improve my job satisfaction remarkably:
"The sitting around on the set is awful. But I always figure that's what they pay me for. The acting I do for free."
Admin
[quote user="KattMan"][quote user="savar] Agreed. I hate the term "rock star" programmer. If such a thing exists, I've never met him (or her). [/quote]
I'm a rockstar programmer, notice no quotes there. I lived off my music for two years before the band imploded. After that I became a programmer. So maybe I'm more an ex rockstar programmer.
I do have to say, the girls were more numerous when I was a rockstar.[/quote]
Pleased to meet you :)
Admin
Enthought Traits has built a system on top of Python which allows you to create complex models which have a nice UI within a very short time because they keep all the stuff in one place (and having a nice syntax for this helps, too).
So instead of defining a DB model and a UI and then trying to match the two, you say:
class Employee(HasTraits): name = Str()
and if you need any validators or special stuff, you pass that as arguments to Str() where the UI and the DB layer will pick it up.
Admin
Oh, man! This is SO me. I am The Developer of The Boring Software. :-(
Admin
I disagree with "Learn Off The Job". Programmers, unlike people in any other profession, have to continue learning throughout their career at the same rate as they had to learn at the beginning of their career. Sure, doctors are supposed to keep up with journals, but anatomy doesn't change.
Admin
Yes it does, it's called evolution!
Of course...I suppose no doctor has to worry about that within their lifetime. ;)
Admin
That's not the title. Typing impaired by a shiny glove?
Admin
This is why I'm glad my job title is "Hydrological Software Developer". Even though I have NO background in hydrology, the stuff I work on is far more interesting than Information Systems.
Admin
It took me 2 days to figure out what's missing in this point of view.
So yes, it is true that writting fancy code instead of straight foward code is done partly to challenge ourself while billing, ultimately, the end user.
Yes, at fisrt glance, coding multi layered apps embrasing the latest techs and philosophies when all the end user wants is record simple data and reteive it later is a bit cheating, the same way the guy at the garage cheats on us when we bring our car. But I felt deep inside me it was OK anyway, and I just needed to find out why, and then stop feeling guilty. And I found out.
There is a limited "supply" of good programmers, and therefor, programming ought not to sucks, or at least not always, cause if it always did, well, we would all leave the boat and the end user will be thrown back to the sixties (not that it would harm much, but that's not what he wants anyway). Even "Sexy" apps, reserved for lucky and gifted programmers, are based or dependant of boring apps, and boring apps developper have to make their job sexy in order to maintain the whole system.
Admin
That all being said: The satisfaction can also come by mentoring other developers.
That and having good hobbies. None of that sucks.
Most of all, bringing home your share of the family income from being professional; making love with your successful wife and having an explosive mutual orgasm with the happiness of your mutual satisfaction. That helps a lot.
Sometimes your lucky enough to code creepware* though. That's always fun! Ok it's challenging. It does leave you a bit questionable in the ethics department. Hmm information systems at least lets you sleep at night. How would developing targeting software for missile systems leave you?
*Creepware: Software that gives you the willies due to its impact on user privacy and the ability of the software or administrator to manipulate the user's social behaviors. Such as software that profiles users to each other (and to content, and to ADVERTISING) but NOT for the purpose of dating...
Admin
Doucher
Admin
Maybe I should be glad that I work in a company where NIH rules the world. Libraries that come with the language? pah! They could maybe not be supported at another system (we only use one kind of hardware) or not work properly with another vendors language implementation (we only ever use one vendor)! But at least, it leaves me the freedom of implementing and learning my own super-uber-hyper-hashtable, I just need to tell that I need a certain feature thats not yet in the inhouse library. A week more to the project? no problem then. And why not add the feature to the inhouse library hashtable already? It was not invented by me, so I won't change it. It makes us happy. And sad.
Admin
This is a wonderful article. It makes a lot of good points. I have degree is in architecture, as in building buildings type of architecture. I am self taught in Cold Fusion but have had the pleasure of having some very good, smart programmers work for me. They were smart, analytical and loved to try out new things. They were an absolute blast to work with. I learned a lot from them.
I also learned that everyone single one of them had an almost compulsive drive towards complexity. Much of my time was spent listening to their suggestions for "improvements" and then asking why them why this was an "improvement." The answer I always got back was a variation on, this is a neat new technology that does cool stuff. Then I would say where is the business case that makes the business money. They would have no answer.
On the other hand you need to keep looking at what is going on in the world. You need to stay tuned into the flow of ideas so that you will stay stimulated and not get board. Keeping up with the new ideas also teaches you that most new software ideas are really old ideas that have been recycled and had a layer of complexity added to them.
Keeping it simple does fly in the face of all the marketing going on. Adding new features is a way to distinguish your product from other products. This creates a large force towards increased compelxity.
Admin
... let alone that hot chick in Database Engineering
Admin
The problem with the article as I see it, is that it's been designed for flame-bait. On the one hand you have a very sensible and useful thing to say: don't write over-complex code when it's not needed, but on the other hand you illustrate it with an out-of-context example that doesn't really seem logical. You might be better using a small example design instead of the code. Currently, everyone who reads the article properly thinks it makes sense and ignores the example, everyone who writes unmaintainable code with hard-coded values sees the example and goes "hey that's what I do, I must write good code!" but everyone who skims the article and notices the example and isn't keen on hard-coding values, or sees problems with it in the future (especially if it would lead to problems in their own language) will assume the article is stupid.
It's always more desirable to write code in a maintainable fashion, with the very rare exception where you know that the thing you're writing will never have to be seen by someone else, and does one function. Even if you're under duress to get somethung out the door, writing good code will doubtless cut down on costs further down the line.
I've recently come across both overcomplex code (about 5 levels of abstraction for everything) which was a result of no real design, and oversimplistic, unmaintainable code (think huge global functions in the same files as huge classes, no scoping of variables, huge switch statements, etc.) which was a result of bad interpretation of the design. We have fixed huge chunks of the overcomplex code over the course of about 2 or 3 months, however, one bug was in the unmaintainable code which took a year to track down.
The reality of the article is that it's about maintainability and not really complex code. If you swing too far either way you're going to end up with huge problems, but in order to be a good coder you need to sit on the centre line, with enough complexity to allow easy extensibility or maintennance (eg taking out those hard coded values into a config) and on the other hand you need to keep things simple enough and not get carried away or you'll really feel it when something needs to be fixed.
Admin
I agree! Programming boring applications really sucks! I really want to create an all singing all dancing framework to make my life easier, but at the end of the day, only the development team will know of this superior engine.
Think of how much it would suck to create the worlds most powerful engine with uber high HP and excellent fuel economy, and not be able to share your stats. Even worst, designing the most beautiful car and only your employer will ever see it, and then he complains of it being too flashy and too many features... That's corporate programming for you!
I am a Software Developer(cool title to make us feel wanted) creating web based applications for the life insurance sector. And it SUCKS! I am starting to freelance and by the end of this year(hopefully) freelance permanently. At least then I can choose what type of project to do...
Admin
You have a chick in DB Eng!!! WTF! I hate you! All I have is internet with pron! At least you can look at something breathing! :D
Admin
I couldn't agree more with this article. I too have fallen victim to the "it's new, therefore it's cool, therefore we MUST use it!!!" syndrome. The end result was that I created (to me at least) amazingly beautiful little pieces of systems but never really finished the job. Definitely did not maintain a reputation for getting effective work done quickly. I've gone back to boring, simple, quick code that gets the job done.
Admin
Are you for real? No wonder no women want to work in your dep't! We aren't there to be porn stars to your "rock stars", we're there to work and get paid for said work. Y'know, like you should be doing instead of looking at porn. FFS.
Admin
#3 seems counterproductive to me. It has often been my experience that at the beginning of a project, I simply didn't know enough about some technology to be able to deliver on the requirements without learning to use new tools and techniques. I regard the ability to learn new things while working on production code to be the most valuable ability a programmer can have - things change so fast these days that unless you're building a system from the ground up, integration with other systems will necessitate learning some technology that you didn't know before the start of the project.
I write code for work, and I write code for fun, but I'm not going to go out and create a personal project that's oriented around learning the things I need to know to perform my job - if what I learn on my personal projects is applicable to work, that's great, but I don't expect it to be. Pushing learning (about tech needed for the job) into off-the-job time is doing nothing more than extending one's work hours.
Admin
damnum, that was a good one ;-)
// damnum captchas
Admin
But that nerdy but still but hittable girl two cubicles down might.
Admin
JT has written a response to this article:
http://jtonedm.com/2009/02/27/business-rules-to-programmers-methink-thou-doest-protest-too-much-i/
Admin
In the beginning, there were no databases, just files, possibly of punch-cards, and it was called Data Processing (DP). A program ran, used an input file or two and produced output files, some reports, maybe paper artifacts like cheques or invoices.
Most of the code as assembler at worst, or COBOL at best (those of us using PL/1 felt special).
Then came hierarchical DBMS and 4GLs so, as noted elsewhere, non-programmers could extract data and write reports, followed by Data Warehouses and cubes and what-ifs; so anyone coding a report these days should be beyond boredom and approaching calcification.
The thing is, there have been successive waves of new languages and tools over the past 50 years. I joined the wave during the hey-day of 3GLs, but with some systems still running using assembler emulators (ah, the emulator, it will always be with us). Assembler programmers looked down on COBOL coders as not really programming.
My first programming used a file management system built in-house at my insurance company employer. Now we have relational DBMS.
Some of that programming was writing reports. The worst was when a business guy used me like a human prototyper, told me what he wanted, I would come back in a week with a great report, he would look at the results and then tell me to change it to do something else. I thought I was done and had done a good job, and didn't like being told to change my good work; he was just doing what-ifs and improving his results based one what he got. ... so I was thrilled to be part of implemeting informational data environments that business people could now do reporting from.
This is just one example of programming that had to be done manually to start, but once it was found that thousands (millions?) of programmers were doing the same thing, a bright person somewhere created something to do it easily or automatically.
There have been succesive waves of this automation of programming. There was also a parallel automation of common domains; I am sure it has been decades since any non-software company wrote its own GL system.
These parallel paths collided in the 90's. CASE tools came along that could generate code, all the code for an information system. Don't scoff, the best tools worked. However, IBM killed the market with AD-Cycle and the big ERP packages came along at the same time and killed most in-house development of any kind.
The thing is, we need these things to happen, or we were going to run out of programmers. Back in the days when operators still manually connected phone calls, it was projected that entire female population of the USA would be needed as phone operators if phone use continued to grow as expected (sexist, I know, but of its time). This is the case with programming; we need new tools and automation to take over the boring stuff so talented programmers can take on the next set of problems that can't be automated, at least not yet.
The latest tools to take away boring stuff are BPM process tools, and Business Rule Engines. Waht is the most boring programming in the universe? Maintenance of existing systems. Let's say in your example that a rule needs another state added to it. If the rule is in code, it has to wait for programming resources and a system release. If the rule is a Rules Engine, the business changes the rule itself, tests it and then puts it in production; no coding needed. That is not pixie dust or over-blown expert systems, that is real technology in use now. When you apply for credit today, do you think all the rules and calcs to get your credit score are hard-coded? Not a chance.
So, if programmers out there want to keep doing the "same old, same old" instead of letting technology do the boring stuff, that's fine. The rest of use will be doing the non-boring stuff.
Admin
I do agree with you statements. I worked for years doing business software, now I work doing development on a big CAD application, and yes, you cannot compare one with the other.
In my years as a business developer I´ve found there are some excuses used to avoid the boredom of doing business software:
One is rewriting the systems every couple of years with a new technology/language (which is, in most cases, a lame excuse to do some fun work). In the CAD app we have some source code that was written in 1988. And lots of code that is more than 10 years old. And a rewrite never crosses our minds!
The other is in-house framework development. In the degenerate case you get a custom application framework for every application the company has. Then again, developing a framework is fun, developing a data-form is not.
Admin
Having the business dictate how software should be written sounds about as sensible as me telling my surgeon where to cut.
At the end of the day it's just an HR issue, some teams of programmers will work well together no matter how clever or not the code is.
Admin
Or, as Donald Knuth said, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
Admin
I have to disagree with the basic premises of the article.
"Whether you’re using Visual Basic 3.0 or XHTML, the concepts are pretty much the same: the database needs to be exposed to the user in user-friendly terms. The code required to do this is, and always has been, fairly tedious:"
Why on Sweet Earth would you write a CRUD application in a general-purpose, textfile-based programming language? Why not a framework that's exactly for this purpose?
I'm writing my code in Microsoft Dynamics-NAV (or if you want something Open Source, check out OpenERP, similar) and I don't have to write any code to link a db field to a form, I just set the SourceTable property of the form designer to the table and drag out the fields in the Field Menu.
If later on the users say the field should be mandatory then I just put 1 line, TESTFIELD("Field X"); into some appropriate trigger. This is a good example how a high-level CRUD application environment works:
all in 1 built-in command.
That's how you build CRUD systems. Not hand-coding everything...
I always wanted to write about this here because there are so many examples of these amazingly low-level approaches to CRUD systems in many examples here that it's amazing... it's a huge waste of money.
Not wanting to pay a lot for Dynamics-NAV? What about Visual FoxPro then? Or high-level free Open Source frameworks: http://dabodev.com/ etc. etc.
Hand-coding CRUD is extremely silly.
Admin
This is where I think you don't understand the article. He is not saying that software is ever boring for him. He says - don't make the problem more complex than it needs to be, just to make it interesting. Solve the real problem you are being paid to solve, with the right combination of practical need and theoretical best practices - be professional.
You can certainly find tons of fun and satisfaction in solving all kind of problems in code, like you state (and I completely agree with that), but that's not what the article is about.