- 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
Agree with the main thrust, though. Don't try to write the cleverest program. Solve the cleverest business problem instead, using your mad design and development skillz. Its actually harder that way, and far more useful, not to mention visible to those both in and out of your department.
Captha: iusto.
Admin
I am interested in these 8.5" disks of which you speak. The ones I saw a couple decades ago on a particle analyzer for an electron microscope were 8.0".
Ed: Whoops, fixed!
Admin
Everyone strives to make the code in budget, under deadline, etc. Real rockstars can do that and create elegant code as well.
Admin
I'm lucky... I get to develop kernel/firmware code for internal use only... in C and assembly, my favorite languages.
What's with all the idiots rushing to be "first" and posting captchas still? Wasn't that last 'cool' sometime last century?
Admin
I agree that coding should reflect the user's needs, but often compiling and deploying software is a pain because of regulations and red tape.
What I like doing when able to is to have the 'hard' code (the side that isn't likely to change and requires speed and libraries and all that) in C++ and the 'soft' code (bound unto the human world of measures and numbers) in a script language such as Ruby. Ruby is immensely more pliable when it comes to doing data structures properly.
Admin
Having worked with it for about four years now, I'm aware that the solution could have been designed just as effectively without all the grandstanding; but it's functional, so we keep it.
Admin
If writing boilerplate code is too grating a task for you, then your framework isn't making things easy enough for you...
Admin
For so long our "profession" has rewarded people who have great coding skills but no skills for requirements gathering, business process design, project management, etc. Because so many of us have poor "soft skills" but are still regarded as acceptable developers by our peers--who else has the capacity to judge?--the business people have increasingly come to think of us as interchangeable laborers. Once you demonstrate that you're no better at requirements gathering and just as good at writing 1000 lines of code as some toothless guy who was herding goats 200 miles west of Xian last summer, guess who's going to get hired to do the 1000 lines of code?
Admin
The point is, elegant code does not equal to "newest buzzword framework", "grooviest language" or even "uses XML". Elegant code can be, say, java 1.4.2, business driven etc.
Yes, I switched jobs to be able to work on a university for a "nutty professor". Now I have to think what, how and why every hour, rather than once a month, an that is my current challenge. Some of the applications I develop are 20+ years old, and I am happy that many of my predecessors were not of the "let's invent the square wheel-with-complicators" type.
Admin
I really enjoyed this article.
I will try to get my co-workers to read this. Some of them just cant seem to "do just what's needed" and the result is more than often overly complex code thats time consuming to maintain.
I always say: pick your battles! Sometimes theres room (time+money) for those truly beautiful solutions and other times just do what was asked for, and move on to the next problem.
Admin
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.
Admin
No, screw you.
Enjoy being business-r4ped everyday and convincing yourself it's the right thing. You probably don't have another option anyway.
Admin
BS "Business" stuff?? Man, you have a job BECAUSE of that business, and its needs for improving their core "business" processes! So don't be all amazed when you need to make code every once in a while that doesn't generate a user input form based on XML composed by your clients, but actually checks if LedgerAmt<=50000...
Admin
I used to do business software (stock-control systems) - and i used to do all sorts of over-engineered stuff.
Now i work on desktop widget software - much happier.
Admin
So...I think I'm going to go throw myself into oncoming traffic now. Thanks for the pep talk.
Admin
"Software development is a unique profession in that we can use our skills both on the job and for our hobby" Utter crap. Mechanics? Carpenters? There are plenty of skillsets that can be used professionally and for personal enjoyment.
Admin
I have to fully agree with the sentiment of this article.
It should be noted that almost all the demotivating factors throughout my professional existence stem from either the business (bad management) or the code base (complex, clever or otherwise unmaintainable code).
"Boring code" is the best code I've ever worked with, and 80% of my time is spent maintaining other people's work.
I'd like to note that most of you will probably code in your spare time, and it's at home that you'll have free reign to write as much clever code as you want.
Admin
Porn star.
Admin
Indeed. And as Michael J. Jackson said in his 1983 Thriller, "Billie Jean is not my lover."
Well, he has seen fire, and I believe he's seen rain as well. Also sunny days that he thought would never end.
Admin
This might be one of the more ridiculous articles I've read in awhile.
This screams of amatuer engineering where an engineer just wants to "get it done" instead of get it done well. That usually results in code that isn't future proof, isn't modular, and is hardly maintainable. Future development cycles end up being a waste due to redevelopment of existing systems.
Using antiquated technology is...absurd. It means you're coding around deficiencies that have been solved in later iterations of the technology. If there has ever been a better way to code yourself into a corner, I haven't seen it.
Learning off the job is all well and good. Learning on the job is better. You're enhancing your skills and your employer directly benefits from that. Better employers recognize this and not only encourage continued learning, but require it (on the clock).
Tedium is not only escapable, it's your job to escape it. You shouldn't be reinventing the wheel and you should not have institutional redundancies. To pick on your example, a UI is one of the easier things to dynamically generate. Moreover, your UI shouldn't have prior knowledge of your model to begin with. The two should be seperate entities.
Still, good luck to you. I doubt we'll be working together in the future.
Admin
I have to fully agree with the sentiment of this article.
It should be noted that almost all the demotivating factors throughout my professional existence stem from either the business (bad management) or the code base (complex, clever or otherwise unmaintainable code).
"Boring code" is the best code I've ever worked with, and 80% of my time is spent maintaining other people's work.
I'd like to note that most of you will probably code in your spare time, and it's at home that you'll have free reign to write as much clever code as you want.
Admin
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.
Admin
Got as far as the bit about "boring" programming, and agree completely: boring programming is boring. So I stopped reading.
Admin
Of course every one thinks they are a bloody rockstar but they aren't. That is why I keep a LART handy to beat the rockstar out of those who think they are.
Admin
Debugging's where it's at. Nothing beats the buzz of finally finding what caused that damn problem at long last!
Admin
Over the years, I've dealt with boredom in several ways, some helpful and some... not so much.
The best way I've ever come up with is to invent ways to make everyone's development process less painful and tedious. Custom debugging tools, build processes, and so on.
Admin
We come to this site to escape the boring and the tedious. What do you give us today? Boring tedium. Jeez!
Admin
If programming weren't boring, who would go to all the trouble to make really cool Easter Eggs?
Admin
Don't write articles like this. You've just told us that:
In short, this whole article is a WTF.
Admin
What a disillusioned and ranting article. Go get a refresher of Brook's beautiful "joys of the craft" article to remind yourself why you became a programmer in the first place:
http://www.davar.net/PROGRAM/EXTRACTS/CRAFTJOY.HTM
Also, maybe we should have a series of "the daily programming gems" instead of daily WTFs to brighten the mood a little bit.
The article seems to make a strong statement for a conservative, keep the status quo, approach to programming. If people really followed this advice we'd still be stuck in the stone age. Sure innovation is oftentimes chaotic and change breeds anxiety - but come on, do you really believe there are two classes of programming problems: sexy ones that allow for innovation and tedious, boring ones that don't? Where would you draw the line? Do you think relational databases are the be all and end all solution to all business data storage needs? Why not fortran flat files then? They have been there before and have been working perfectly adequately for years?
How come that innovative solutions to boring problems are usually the ones succeeding big? 37signal? Boring problem. Innovative solution.
I have learned to find interesting problems in even the most boring domains - even without complexifying it unneccessarily to please my programmer ego. And I have worked for cutting edge, research oriented, image analysis shops as well as on coporate enterprise resource planing and customer relations management stuff. I couldn't even say where I have learned more or which of them were more interesting - although according to your narrow definition one of those is clearly sexy and the other just interface for data (isn't that the very definition of a program btw? algorithms and interfaces on data?).
Don't learn on the job?! That must be the most WTF advice ever - try suggesting that to your boss: "Sorry, I'm not interested in learning about boring problems, I prefer to advance my knowledge at home!".
cheers,
Admin
I was going to say something to this effect, but EvaUnit02 said it much more eloquently than I could.
Look, one doesn't design and write modular code for our own recreation. Writing spaghetti code (for which "soft coding" is a euphemism) may be acceptable for small projects, but the value added by reduced development costs simply cannot be justified considering the added maintenance and testing costs, and the propensity for bugs to emerge that incur substantial costs on end users. Well-designed, modular code (which you deride as "all sorts of design patterns, interfaces, supplementers, and a whole lot of classes") is for all but the smallest projects in the business interest of the client, and not for the personal satisfaction of the developer.
Well-designed code requires a higher upfront cost at the design stage because factors like modularity, security, extensibility, and scalability are embedded into the final solution. The costs are recouped in more secure, more robust software that is more cost-effective to maintain, expand, and suit the business needs of the enterprise.
Alex, you write that "The true rockstars can deliver software before deadlines, under budget, and that does exactly what the business needs." With all due respect, this is nonsense. Applications have lifetimes that far outlast the development lifespan, and we have seen countless examples on these pages of undocumented, uncommented, unmaintainable spaghetti code that is easier (and would make more business sense) to replace entirely than maintain. You are calling the writer of such awful code a "rockstar", the penultimate programmer. I profoundly disagree.
Admin
I'll take adding two more lines of source, recompiling, and rereleasing, thanks. Read the article that code was quoted from, you seem to have missed the point entirely.
Admin
Admin
I must confess I agree with the article. Doing only what is needed is the only efficient and productive method of working. Plug-ins and offering the 'just in case we need it in the future' option rarely pay off and just cuase more problems.
I feel lucky that during my day job I help with the large-scale bespoke framework the company insists on developing, whilst out of work I help my dad with embedded systems, with tight limits on hardware that any of this 'trying to progress for the sake of it' doesn't go on - not a lot to do with 128 bytes of RAM. Work pays the bills, out of work challenges me.
Admin
I think Dickens said it best when he wrote "IT was the best of times, IT was the worst of times."
Admin
This article sucks.
Good job. You've highlighted the problem and then said "Suck it up and act like the tool you are."
Way to think inside the box, Alex.
Admin
kind of agree with the article... but this really applies only to small-ish applications with limited scope. the more users, the more code, the more scope... the more you NEED people who use all those crazy interfaces. that kind of thing makes life easier down the road. :)
for the basic internal app, you're spot on, and I've seen dozens that were over-thought and ended up being a PITA to maintain because of it.
loving the comments from the folks on here, too... quite a disparity between the programmers I'd never want to work with and the programmers who agree with the article...
Admin
Actually, I'd say this screams of someone who's had to work in a business environment where lovely shiny happy code isn't the top level driver, but the business is instead. If you're working in a company where a problem's causing problems for the sales force leading to lost opportunities, poor forecasting leading to factory component overstock or the like, do you go for the simpler established solution that you can get working in a couple of days, or do you go for the more elegant solution that will take a couple of months? Because if you chose option 'b', it is highly unlikely that you'd be working in the same company as anyone who chose 'a', because you'd have been shuffled out the door very quickly. The company's losing money while you fanny about getting the nuances of the new technology you've fallen in love with sorted. Getting it done well enough is almost always more important than getting it done perfectly.
Using the obligatory car analogy, you're talking about trying to develop something like hybrid electric/biofuel as next year's model at a manufacturer that builds petrol driven cars. It might be more fuel efficient, it might be a wonderfully interesting thing to implement, it might lower costs over time, it might be something for the R&D department, but as it's needed for next year it's not going to be ready in time.
Admin
I agree with everything here except that any of it sucks. It is a joy to write clean and well structured software that solves mundane problems. That joy comes from the satisfaction intrinsic in doing a good job. Being professional doesn't suck at all. Being professional is the most fun of all.
Note From Alex: I definitely agree, and hope this setiment came out in the article. I love doing what I do, not because of the "boring" tidbits of code required to do the job, but because of the overall value I can deliver.
Admin
Alex, it should be Principles of Program Design. Cheers.
Admin
That's exactly his point. You (YOU) don't know the project. You don't know the business. Is there actually any need to have these values configurable? Is there anyone who will (be able to) maintain that configuration? Is there a business process that drives that maintenance? If not then the users will probably ring the manufacturer anyway to have something changed here. Is is difficult to deploy a new version? Maybe its not. Maybe its interpreted code like PHP even, so no recompilation necessary, no downtime even involved. Probably the stateCode values never change, but new ones are added. So you will have to add logic here anyway and configuration doesn't solve that problem.
This code is simple. Anyone can understand and maintain it. Even a guy that's new on the project. There is no need to make it more complex. Changing it without knowing the business is like premature optimization without profiling.
Admin
It's still fun. I love what I do for a living.
Admin
Yea, that's it. I think I'm going to be unsubscribing.
This article is supposed to be what, exactly? Enlightening?
Writing straightforward code instead of clever code sounds great, but when you have a million lines of copy-and-pasted HTML with scattered bits of PHP to generate each page individually, you really have to ask yourself if you would have been better off spending some time on proper design.
Whenever you can make the codebase smaller without sacrificing features, it's usually a design win. And it's the exact opposite of what you're preaching. Sure, you need to define your database fields, and then define the name, label, and limits of the field for the frontend, but your framework should do all the rest: generating client-side validation, performing server-side validation, generating error pages, pulling and pushing data to and from the database. And you should have the ability to template in any common UI elements.
And it doesn't even take a very "clever" framework to do all that. Once you have that framework, adding a new type of report generation involves one new database table and about 20 lines of clean, simple code with very little that can go wrong.
Why not spend some of that effort on detailing good, robust design processes, good factoring, and the like, instead of just ranting that you should hate your job. The more your code paths converge, the fewer places bugs can hide.
Avoiding bosses who believe as you do is why I changed careers. Hardware is much less forgiving of "just do it" attitudes and poor engineering rigor.
Admin
As far as I'm concerned there is absolutely no defending the "inspired-yet-misguided" coder and I would agree that they are vastly more of a problem than the inexperienced or sloppy coder. Even referring to them as inspired-yet-misguided is way too generous since these are the people whose architectural behemoths of mistakes take weeks or months to unpick (and sometimes never get unpicked at all).
I don't consider a coder to be inspired or even proficient if they let their personal desires drive their coding decisions. It doesn't matter how much raw skill you have, if you don't have the discipline to apply it correctly then you are not a good coder. Interestingly, you will very often spot other major failings with this type of coder. For example, I find they will often push ahead with new code at the cost of maturing their existing code. Instead of adding decent comments to the class they just wrote they're pushing on and writing the next one. If the drive for new code comes at the expense of maintaining the existing code then you've got another problem on your hands.
As a general rule I consider these coders to be lost causes and spent my tutoring time on the juniors, who stand a very real chance of being vastly superior.
Admin
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.
Admin
I certainly don't agree with the whole article - for instance, learning should be integrated with the job, not set apart from it - but some good points are made. There are tons of devs out there who aren't nearly as brilliant as they think they are, but still attempt to write clever code - code that makes the rest of us want to throw ourselves under trucks.
I think it's pretty safe to say that that the truth is somewhere in the middle. Real rockstars know when to build the wizbang 9000 and when to KISS. In my humble opinion, it boils down to how easy it is to maintain the final product.
Admin
While I do agree with the spirit of your article Alex, I think decisions like this need to be decided on a case by case basis.
Case 1 (Training management app): This web app was developed to Allow employees to sign up for trainings (Mandatory and optional) as well as request them. It hooks into Active Directory and exchange server. It allows individual users to track what courses they have taken, What ones are offered, etc. HR can also see who has taken what, etc. There are other features, reporting, outlook integration, etc. When we developed this app we knew that it was going to stay more or less the same for a long time without any changes. Such has been the case. I've had to fix 3 bugs in 2 years. We made the decision not to make this system overly complicated with creative code. took us about 2 months to make once specs were finalized.
Case 2 (A very high profile app in the healthcare industry in massachusetts): This application we knew needed to encompass a pda version as well as a web app accessible to healthcare providers via vpn. Sql server CE on the pda's and Enterprise on our end. This app would include forms that would change with both state and federal regulations via tweaks to the project it was the backbone for. Basically the application has to change and evolve with the project. This being the case we decided that it would be better to make it more "enterprisey" as we would constantly be modifying it to meet the state's (our only client) needs. Again it has worked out extremely well and helped mitigate serious issues in the healthcare industry in massachusetts. If you want links to info on the project pm me and I will send them.
Admin
I write boring code. I write code that meets the business requirements and is as simple as possible. I also use descriptive variable names, normalized tables and all the other things that could be done 'creatively'. I also try to make my code comments as relevant and useful as possible.
Why do I do this? Because that's the way I would want to see the code if I were doing maintenance. And because that's what is needed.
Admin
If writing software is boring, the problem is not the software. I have written business rule databases, math engines, double-entry bookkeeping systems, GUI frontends to scientific equipment, and the only thing that they all had in common was that I had a great time doing it.
Maybe it's just me, but writing software is about solving problems, and I find that interesting and fun regardless of the application. "Sexy" is in the eye of the beholder. At the end of the day Google Maps is just another map application, the iPhone is just another mobile device, and anything written in Visual Basic is--well, okay, that one's probably not ever sexy.
If you're not having fun, you're doing it wrong.
Admin