Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How To Develop Unmaintainable Software

Soulskill posted about 10 months ago | from the just-do-what-comes-naturally dept.

Programming 211

jones_supa writes "Greg Jorgensen specializes in debugging, fixing, maintaining, and extending legacy software systems. His typical client has a web site or internal application that works, more or less, but the original developer isn't available. Greg lists some things you can do in your own software projects to keep him in business. In summary, the list goes as follows: Customize your development environment a lot, don't make it easy for the next programmer to start working on the code. Create an elaborate build and deployment environment and remember to leave out the documentation. Don't bother with a testing/staging server but instead have secret logins and backdoor URLs to test new features, and mix test data with real data in your database. Don't bother with a well-understood framework, write everything from scratch instead. Add dependencies to specific versions of libraries and resources, but don't protect or document those dependencies. For the icing of the cake, use the coolest mix of cutting-edge programming languages."

cancel ×

211 comments

Sorry! There are no comments related to the filter you selected.

Tied this (2)

Urban Nightmare (147344) | about 10 months ago | (#45137473)

and I was still replaced.

Re:Tied this (1)

Anonymous Coward | about 10 months ago | (#45137523)

If your name was on it, I bet you'll have a much stronger network to job hunt from. The best programmers code themselves "out of a job". They're called consultants.

Re:Tied this (5, Informative)

Samantha Wright (1324923) | about 10 months ago | (#45137599)

Well, maybe you should try this much more venerable, thorough, and entertaining encyclopedia of unmaintainable code tips [mindprod.com] . Should make you as immovable as the CEO's firstborn.

Re:Tied this (1)

QRDeNameland (873957) | about 10 months ago | (#45138059)

Ouch, my eyes!! You'd think someone with something insightful to say about development would re-think that GeoCities-esque web design.

Re:Tied this (5, Funny)

crunchygranola (1954152) | about 10 months ago | (#45138117)

Well, maybe you should try this much more venerable, thorough, and entertaining encyclopedia of unmaintainable code tips [mindprod.com] . Should make you as immovable as the CEO's firstborn.

He has an unfair advantage in the area of unmaintainable code since he is writing about C/C++.

Re:Tied this (1)

Samantha Wright (1324923) | about 10 months ago | (#45138649)

If it's about any specific language, it'd be Java (though lots of languages are mentioned); note the title.

Re:Tied this (-1)

Anonymous Coward | about 10 months ago | (#45138009)

Become a maintainance programmer for Obummer's market place website. You'll have work for years untangling it.

How To Develop Unmaintainable Software (-1)

Anonymous Coward | about 10 months ago | (#45137483)

uhm... is this about Obamacare IT?

Re:How To Develop Unmaintainable Software (0)

rudy_wayne (414635) | about 10 months ago | (#45137595)

uhm... is this about Obamacare IT?

I thought he was talking about Firefox:
- Customize your development environment a lot, don't make it easy for the next programmer to start working on the code
- Create an elaborate build and deployment environment and remember to leave out the documentation
- Don't bother with a well-understood framework, write everything from scratch instead
- Add dependencies to specific versions of libraries and resources

no PHB driven IT (1)

Joe_Dragon (2206452) | about 10 months ago | (#45137613)

no PHB driven IT where is your TPS report?

Re:no PHB driven IT (0)

Anonymous Coward | about 10 months ago | (#45138021)

How is that different from what the GP said?

Re:How To Develop Unmaintainable Software (4, Funny)

Beardo the Bearded (321478) | about 10 months ago | (#45137865)

In all fairness, outsourcing it to Canada made sense. We're cheaper, we have health care already, and speak English with an approximate degree of usefulness.*

So, on behalf of our country, I apologize for any inconveniences you have suffered from the sheer shittiness of the ACA software. As a measure of our sincerity, you may pick up one(1) bottle of maple syrup from our strategic reserve.

*offre non valable au Québec

Old news (3, Insightful)

Pharmboy (216950) | about 10 months ago | (#45137487)

This is old news. These methods have been around at least as long as C has. It only works in isolated situations and doesn't make you a good programmer. Or person.

Re:Old news (1)

Anonymous Coward | about 10 months ago | (#45137543)

This wasn't another "how to job security by being a shitty dev/person" article. It was a tongue-in-cheek list of mistakes made on projects that make future maintenance a nightmare. Least that's how I interpreted it.

Summary kinda implies a different tone. I suspect plenty of kneejerk in this thread!

Re:Old news (3, Insightful)

lgw (121541) | about 10 months ago | (#45137583)

Not every programmer was around when C was new. Everyone needs to learn these lessons, and preferably not the hard way.

I'm mean, you'd think anyone starting a major project today would use version control, that shouldn't even be a question, right? Right?! Sigh.

Some of his other stuff on his page is quite entertaining as well, like this one on Abject-Oriented programming [typicalprogrammer.com] .

Re:Old news (1)

Anonymous Coward | about 10 months ago | (#45137817)

Not every programmer was around when C was new. Everyone needs to learn these lessons, and preferably not the hard way.

I'm mean, you'd think anyone starting a major project today would use version control, that shouldn't even be a question, right? Right?! Sigh.

I can take that a step further. Recently I came across a source code, which used it's own method of ensuring that everybody were up to date. It placed the entire source tree, project files and temp files in dropbox. I mentioned using svn/git and it was answered with "why? This approach works. There is no need to make it more complicated without any benefits"... I quietly and successfully backed out of touching that code. The coding skills used in the code were equal or worse than the source handling would indicate. Amazingly the compiled app actually worked with no major bugs or performance issues, which actually concerns me a bit. How many closed source apps do I have on my computer of that quality without knowing it?

Re:Old news (2)

dgatwood (11270) | about 10 months ago | (#45137873)

How many closed source apps do I have on my computer of that quality without knowing it?

"Most of them" would be my guess.

Re:Old news (0)

Anonymous Coward | about 10 months ago | (#45138015)

"the compiled app actually worked with no major bugs or performance issues"

So what the hell are you bitching about? Why are you "concerned" that it did what you expected it to?

Re:Old news (1)

Anonymous Coward | about 10 months ago | (#45138449)

"the compiled app actually worked with no major bugs or performance issues"

So what the hell are you bitching about? Why are you "concerned" that it did what you expected it to?

Working as expected mean it's ok right now, but what if next version should contain some additional features? It's near impossible to code on something where the concept of local copy is gone. Guy A change one file and guy B change another. Who made the resulting crash? It could even be guy C as he also changed something and now that hell broke loose he didn't tell and without a log A and B wouldn't know C did something.

The "it's impossible to code on, but it works, which mean everything is ok" can only be used if no further development is planned for the said code. Bugfixes is also development in this context.

Re:Old news (4, Interesting)

hurfy (735314) | about 10 months ago | (#45137883)

lol, 25 years ago we had ONE programmer able to maintain our software as he had done much of the customization of an out of the box accounting system. Bloody thing was so complex to start with noone wanted to touch it before we fixed it up, much less afterwards. Upto 10 Megabytes worth of code but no more than 32K loadable in memory. Must have been 100's of small chunks of code all calling each other in and out of memory every other keystroke.

I managed to customize some reports but that was only part i ever dared to touch.

The real kicker...written in a version of BASIC.

Actually a pretty impressive system and worked well for 15 years. Always wondered how they managed to write such a monstrosity. Kept picturing a blimp hanger with a flowchart wrapped around the walls.

Re:Old news (0)

Anonymous Coward | about 10 months ago | (#45138415)

Must have been 100's of small chunks of code all calling each other in and out of memory every other keystroke.

Emacs?

written in a version of BASIC

Oh.

Re:Old news (2, Insightful)

girlintraining (1395911) | about 10 months ago | (#45137929)

This is old news. These methods have been around at least as long as C has. It only works in isolated situations and doesn't make you a good programmer. Or person.

A lot of that list is pretty damn arrogant, or at least naive. Let's start with just the ones the submitter quoted;

Don't bother with a testing/staging server but instead have secret logins and backdoor URLs to test new features

If you're so well known you can dictate terms to your employer, then maybe you can get away with this... for awhile anyway. But most of us, who code for a living, have to do the best with the tools we're given. We can ask for a testing server, but whether we get one is another matter entirely.

As for 'secret logins' and 'backdoor URLs'... every login is supposed to be secret. If you can get a list of userIDs via any external method, that's a security risk. And as for 'backdoor URLs'... Not everything should be accessible to the google crawler.

and mix test data with real data in your database.

There's any number of failure modes in complex code in which shoving random inputs into it will cause it to break in unexpected ways that don't become apparent until properly-formatted data is submitted after. I think what the author was trying to say was not to put invalid data into a production environment on purpose; It might make the app shit a brick. Unless of course that's the only environment you have to test. See also: That 'routine backup' of the EBT system that caused 13 states' food stamp programs to die in place.

Don't bother with a well-understood framework, write everything from scratch instead.

Again, pure arrogance on the part of the author; Well understood frameworks tend not to be highly optimized. If you are dealing with something where performance is absolutely critical, writing it 'from scratch' will probably get you better performance than taking one of those 'well-understood frameworks' out for a drive. Because as most experienced programmers know -- well-understood frameworks also have a lot of extra features and bloat they don't need. See also: .NET

Add dependencies to specific versions of libraries and resources, but don't protect or document those dependencies.

Okay, that's just plain sloppy. Well, 1 out of 5.

For the icing of the cake, use the coolest mix of cutting-edge programming languages.

The choice of programming languages matters very little, except to those who lack the Tao of programming. For those who are not One with the code, who do not grok the larger patterns that permeate the spaces between that which only the machine understands, and that which only the human understands, the language choice is the difference between life and death. For those who have transcended languages... it is the patterns they seek to understand. The language will take care of itself. It's like saying "Love" in French, German, Russian, or English. It's the same damn thing, and it's possible to understand someone who loves you, even if you don't understand a bloody word they say.

Bottom line here is that this 'list' is just the logical conclusion of a career of mediocrity spent shifting blame around instead of working the problem. Real programmers can use anything; And frankly... they usually do. -_- I've seen some completely hair-brained solutions that are coded in Perl, cgi-bin, bash, PHP, and little chunks of C here and there that work flawlessly and at great speed because the programmer took the best of each of those languages and leveraged them in the solution. Of course, for every good programmer who does this, there's ten more who tried the same thing and wound up with a pile of half-working shit, sooo.... YMMV.

Re:Old news (4, Insightful)

lgw (121541) | about 10 months ago | (#45138311)

Well understood frameworks tend not to be highly optimized. If you are dealing with something where performance is absolutely critical, writing it 'from scratch' will probably get you better performance than taking one of those 'well-understood frameworks' out for a drive.

Sure, of course, why not. It's not like your time is valuable or anything. And naturally, you will make this decision before coding starts, and thus before any measurements that the framework was actually slow, or for that matter that it was part of the perf bottleneck of the system. Nothing says "job security code" like elaborate cryptic algorithms to improve asymptotic performance of some in-memory task on a system where CPU never got above 5% in the first place.

Let's not forget how bug free a framework used widely by thousands will be - there's no job security there at all if there's no bugfixing! But if we write our own, then there will surely be some horrific bug in the field that we can work until 4AM to fix, and management will call us heroes!

The main thing, of course, when writing your own replacement for some common library that some new hire would already know is to avoid any documentation, and ideally abandon the effort halfway through, because the project ran out of time, only ever use 10% of what you wrote, and never document which 10% - heavens no!

To make doubly sure that no new hire could ever support this code, remember to follow this key element of Abject-Oriented Programming: [typicalprogrammer.com]

Documentation
  It's said that code should be written for people to read, so it follows that documentation is written for no one to read. Documentation should be written for every new module and then maintained as changes are put into production, or at least the next time thereâ(TM)s a lull in the workload.

A good time to write documentation is when someone in the department gives two-weeks notice: use that time to make sure the departing team member documents all of their code.

Cluttering up the source code with lots of comments explaining what the code is trying to do is distracting and slows down the compiler. That's why abject shops that follow "best practices" keep documentation in a document management system where programmers can't accidentally delete it.

Sage advice, I'd say.

Bottom line here is that this 'list' is just the logical conclusion of a career of mediocrity spent shifting blame around instead of working the problem. Real programmers can use anything

Perhaps you missed the part that the author of TFA makes his living answering panicked calls to bugfix production legacy code, presumably because some "real programmer" did in fact "use anything", and this advice is based on long experience of what makes code unmaintainable. My own experience/advice lines up with his rather well in this area, I'd say.

Re: Old news (1)

techprophet (1281752) | about 10 months ago | (#45138341)

How often are the things done by frameworks performance critical? Last I developed a site in django, the most time consuming operations were database queries (which are easily done outside of the Model system if one so desires), but writing the sql manually would take much more time for very little benefit. Likewise, rolling your own templating system is virtually worthless when dealing with your average site: the db queries simply dwarf the render time and a half decent caching system will further reduce the impact of writing your own. In my experience most programmers cannot easily write code that is both maintainable and faster than a library version. They (and I) can do one easily, but not both. Writing the absolute fastest code is worthless for 99% of software, as most software is not limited by the hardware. That time is better spent on robust testing and feature development.

Re:Old news (2)

Draknor (745036) | about 10 months ago | (#45138611)

I think you are missing the author's points in your rebuttal.

Testing server -- maybe it's not ALWAYS possible with expensive enterprise-y server software, but just about anyone can spin up a VM on their dev machine to simulate (with varying degrees of accuracy) a production environment.

Secret logins & back doors -- you mean you've never created a "god" or "super admin" account (or "secret URL") that could access all kinds of technical / debugging info that regular admins/users shouldn't see? Having such an account means your application has additional logic & code paths to support -- code that's probably not being adequately (if at all) tested and probably has bugs, some of which may be security-related.

Test data in production - yeah, I've worked on systems (such as health care IT systems), where project team puts test data in the system. It sucks for operational users. "What, you mean Dr. Smith doesn't have a 2pm appt w/ TEST, DUMMY today?" "The compliance dept just got a call about a six-figure insurance claim to Medicare for a pregnancy-related hospitalization for a DUMBASS, JOE -- anyone know about that?" Test data belongs in a test database.

Frameworks -- in my humble opinion (and I'm not exactly alone [c2.com] ) there are very few situations where run-time performance is actually "absolutely critical". More often (in my experience) time-to-develop "performance" is a bigger factor, and rolling-your-own (to get alleged better run-time performance) will cost you development time, bug-fix time, QA & testing-time -- which, for the vast majority of applications, will cost more than simply buying faster hardware (the happy medium way is to optimize just the critical slow parts in your application that the framework handles sub-optimally).

Choice of languages -- again, I think you missed the point. Any language is fine. His point is to keep your project consistent. If you've developed a hair-brained solution that involves Perl, cgi-bin, bash, PHP, and chunks of C -- it probably works great and flawlessly, like you said. Until that programmer (1) retires or (2) gets hit by a bus. Then the junior programming intern they hire to take his place is screwed. And that's the author's point -- write maintainable code. A mismash of languages & bindings "because they are cool" may function, but it's not maintainable. If your star programmer has this Perl/bash/PHP/C contraption and it's well-documented and logical, then maybe that junior intern will take it over and, with a bit of a learning curve, master it. But if your programmer used 4 different languages because "it's cool to make it complicated" -- well, good luck.

Great little article (5, Insightful)

Anrego (830717) | about 10 months ago | (#45137501)

Every one of these points hits the nail square on the head.

The key to take out of this is: document document document! At minimum you should have a set of instructions to re-build your dev and build environment. "Insert the <your company> dev workstation image v4" is not allowed to be a step! Your elaborate continuous integration multi-tree setup and mountain of environment setup scripts and template directories are great until the guy who set it up takes off and you have to upgrade something. Ideally a set of instructions talking to the motivation of certain decisions, roadblocks encountered, etc.

One thing the article doesn't have is have lots of 3rd party tools and keep the license servers/license files on whatever box is most convenient for the dev working on it at the time.

Re:Great little article (2)

phantomfive (622387) | about 10 months ago | (#45137783)

"my code is self-documenting."

A statement that is always true as long as no one else has to read it.

Re:Great little article (0)

Anonymous Coward | about 10 months ago | (#45138183)

Every one of these points hits the nail square on the head.

You must only know how to use a hammer (just kidding).

Many of his points are fine, but a lot of them really miss the mark. A web application which is a straight checkout? Come on! That's a very bad idea. It should be something like, checkout, make, make install (or mvn package, unzip in deployment directory). There is just too much at risk to have a SCCS directly drive your deployment area, especially if that SCCS tends to cache URLs back to the repository (or contains passwords or hashes of passwords).

Separating the build and deployment makes it _easier_ to have differentiated dev, test, and production servers, but this guy is just ignoring all of that. The best that he gets is a marginal ability to fix in place and check back in; but, those techniques are exactly how you side-step all regression testing.

Re:Great little article (1)

Anrego (830717) | about 10 months ago | (#45138261)

SCCS

That sounds famil.. oh god! The memories... sccs, mergegj, teamware! Make it stop, I don't wanna play anymore!!!

Kidding aside, SCCS and it's best friend teamware may actually be satan.

Agreed. Never seen "too much" documentation (1)

Anonymous Coward | about 10 months ago | (#45138249)

It's always been insufficient for a new team member to do everything they need to do. And no, "just ask Dave, he knows everything" is the claassic mistake that so many people make in excusing this, as it assumes that he will always be around to answer questions (in practice, he will be so snowed under keeping the damn system afloat that he never has time to help as there's always something "more urgent").

When will the majority of developers ever learn that documentation (instructions for humans to make the system run) is as vital as code (instructions for computers to make the system run) ?

And how many businesses have sunk into the swamp of failure because of arrogant jerks who like to say stuff like "my code is self documenting" and clueless managers who have no development background and let them get away with it.

There are more abstract, higher levels of "information" that need to be valued in the "Information Technology" business than code and data.

Calm down, Satan. (0)

Anonymous Coward | about 10 months ago | (#45137509)

Note subject.

Ahem... Meritocracy (0)

Anonymous Coward | about 10 months ago | (#45137549)

Just ask my former boss any questions you may have on the code or build environment. He's my boss, of course his knowledge would be a superset of my knowledge. That's why he is paid more than I was when I left.

Go "Maximizing Shareholder Value"!

Your Boss (1)

Anonymous Coward | about 10 months ago | (#45137587)

He was paid more because he assumed more responsibility than you, not because he has more esoteric knowledge than you.

But he is probably smarter than you, because he understood the above.

Re:Your Boss (0)

Anonymous Coward | about 10 months ago | (#45137671)

Well, no, he quite literally didn't. Unless, of course, the prioritizing the state of the code wasn't important enough to need to be "responsible" about, in which case the discussion is moot.

You are probably one of those people who thinks, say, a CEO has a lot of responsibility, rather than the reality that he has virtually none. A delegatable "responsibility" is functionally a responsibility in no way in present society.

And although this is all hypothetical, he almost certainly isn't smarter than me, as a matter of statistics.

Re:Ahem... Meritocracy (1)

Punto (100573) | about 10 months ago | (#45137999)

Unless your boss hired you to delegate a task he can't or won't do.

Revision control systems are not installation syst (1)

rminsk (831757) | about 10 months ago | (#45137559)

svn up git pull hg pull

Quoting user tdammers on reddit:

  • Excess files in document root - version control cruft, project documentation, etc. Happens all the time, and is an actual real security problem.
  • Development race conditions. Ever done svn up on the production server, just to find that someone had committed broken code between your test run and the deployment? Ever "solved" this problem by stopping all development activity during deployment? Ever noticed how this essentially means that this makes frequent deployments practically impossible?
  • File permissions and ownership. Need I go into detail here? I think not.
  • What if you want to do things like precompile templates, preprocess CSS, minify and concatenate your JavaScript offline, move stuff around, or just make sure that your deployment will only go through if it passes a minimum set of tests?
  • What about database changes?

Re:Revision control systems are not installation s (1)

Jorgensen (313325) | about 10 months ago | (#45137769)

Development race conditions. Ever done svn up on the production server, just to find that someone had committed broken code between your test run and the deployment

If this happens, then you are doing things wrong.

You should know that YourApp version X is what QA tested. Because the developers tagged it before giving it to the QA guys.

You should know that upgrading your live environment to YouApp version X is not the same as "Upgrade live to latest commit". This race condition is easily solved by proper understanding of how people use your version control system.

In other words: Use the tags, Luke!

Arguably, using "svn update" (or whatver equivalent in your chosen VCS is) is only useful for projects that require no compilation or installation other than "just copy files about". Most are more complex than that.

Re:Revision control systems are not installation s (0)

Anonymous Coward | about 10 months ago | (#45138045)

Or don't use SVN. Life's too short.

Re:Revision control systems are not installation s (1)

Cramer (69040) | about 10 months ago | (#45138113)

It's even simpler than that... what one tested is svn status. That revision is what you deploy. There's no need for branching, tagging, or an of that crap. SVN has repo revision numbers. Use. Them.

(this is the reason our products have the svn rev in their product version - so we know exactly what was used to make it.)

Use a language that no one ever heard of (2)

jfdavis668 (1414919) | about 10 months ago | (#45137561)

We inherited a system written in a language we never heard of. It wasn't just uncommon, it was way out there. Unfortunately, It was a while ago and I don't remember what it was called. We ran the system, but had to rewrite it immediately. Luckily, the reason we inherited it was because the old system was crap, and the customer was willing to pay us to redesign it. If the previous vender had put a little more effort into it, we wouldn't have been able to take the business.

Re:Use a language that no one ever heard of (0)

Anonymous Coward | about 10 months ago | (#45137691)

I write everything in LOLCODE [wikipedia.org] , although I'm thinking of mixing in a custom version Scheme where all parens are instead whitespace.

Re:Use a language that no one ever heard of (0)

Anonymous Coward | about 10 months ago | (#45138497)

That would be awesome! But there will be wars as to whether a newline opens a new block or closes the previous block. I suggest instead that you use space characters to open and backspace characters to close...

Re:Use a language that no one ever heard of (1)

techno-vampire (666512) | about 10 months ago | (#45137777)

Back in the early '80s, I did some work at JPL. Much of our work was done in a language that we were the only two people who'd ever heard of it: MPL. Why? Because it was a custom pre-processor that my partner had written for PL/1 to add all of the syntactic sugar automatically. No, I never knew why he didn't just include a set of macros and use the regular pre-processor. For all I know, it wouldn't do quite what he wanted it to do.

Re:Use a language that no one ever heard of (1)

jfdavis668 (1414919) | about 10 months ago | (#45137921)

PL/I was the first language I actually learned. Did some work in Fortran before that, but all I could do was modify a program someone else already wrote. That was the strange thing about this obscure language. I had run across so many, PL/I etc, APL, COBOL, SNOBOL, Scheme, Lisp, Prolog, Pascal, Ada, Smalltalk, C. You think I would have at least heard of it. It bugs me I can't remember what it was called. It wasn't a variation of some other language.

Re:Use a language that no one ever heard of (1)

Arker (91948) | about 10 months ago | (#45138121)

Just a shot in the dark but was it OCAML?

Re:Use a language that no one ever heard of (1)

altgeek (557342) | about 10 months ago | (#45138707)

Try the listing / chart at http://www.levenez.com/lang/ [levenez.com] . Good luck...

Re:Use a language that no one ever heard of (1)

avandesande (143899) | about 10 months ago | (#45137923)

APL works perfectly with Twitter Bootstrap. Send me some money and I will tell you how...

Re:Use a language that no one ever heard of (1)

djbckr (673156) | about 10 months ago | (#45138165)

I had a similar situation. I inherited a company program that was written in a language called Magic [stackoverflow.com] . It was some sort of table-driven record-based language that, to code, literally went up one side of the screen and down the other. It was as bad as it sounds.
I rewrote the software in Delphi (this was back in the 90's) and it was orders of magnitude faster.

My favorite (1)

Anonymous Coward | about 10 months ago | (#45137573)

I had the pleasure to review some code that attempted to be unmaintainable. My favorite was the unused variables and dummy logic in mysterious functions similar to this:

private boolean myfunction(int param) {
      int a=45;
      int counter = -1;
      int d=0; ...
      for (int i=0; i<32; i++) {
            d = i + counter;
      } .....
      [do some real processing based on the param] .....
      return true;
}

Re:My favorite (1)

Mordok-DestroyerOfWo (1000167) | about 10 months ago | (#45137887)

So that's where I left that code! Sorry, brah.

Frameworks (3, Interesting)

Tablizer (95088) | about 10 months ago | (#45137611)

Don't bother with a well-understood framework, write everything from scratch instead.

Is this saying only use widely-available frameworks (to do it "right"), or don't write your own frameworks from scratch? I have time-tested C.R.U.D. frameworks I often use for web projects that I've improved and tuned over the years. They are reasonably well-commented.

Re:Frameworks (1)

phantomfive (622387) | about 10 months ago | (#45137839)

Custom work is ok, as long as two requirements are met:

A) it works
B) it is easy for a new guy to pick up.

Those are the main benefits you are getting from a well known framework, so as long as you hit those requirements, you are fine. A lot of people who write their own custom frameworks fail at both, they are constantly trying to fix their framework, debug it, get it working, which is a mess.

Re:Frameworks (1)

Fnord666 (889225) | about 10 months ago | (#45137897)

A) it works
B) it is easy for a new guy to pick up.

Those are the main benefits you are getting from a well known framework,

Just because a framework is well known does not imply either of these two things are true.

Re:Frameworks (1)

phantomfive (622387) | about 10 months ago | (#45138085)

The point of it being well-known is that you can easily hire people who know how to use it, so that is why B is important for custom frameworks......if you can't hire someone who already knows it, then it better be easy for newcomers to learn.

For A, of course not all well-known frameworks work, but you can know which ones to avoid, or at least what kinds of troubles you'll run into. I suggest avoiding PHP, but if you use it without being aware of the drawbacks, it's your own stupid fault.

Re:Frameworks (1)

lgw (121541) | about 10 months ago | (#45138373)

Is that "whooshing" sound you hear familiar to you? I suspect you've heard it before.

mo3 do3n (-1)

Anonymous Coward | about 10 months ago | (#45137623)

part of GNNUA if

Write your own language! (1)

bunyip (17018) | about 10 months ago | (#45137635)

Just get a hold of lex & yaxx, antlr or your favoriate tools and write your own language. You could probabyl abuse Lisp macros anough to do this too. I once worked with a company where the lead programmer had invented Hugh-BOL, and that's what they coded in.

Now, I do admit that a DSL it the best approach from time to time, but there is an limit...

Re:Write your own language! (2)

dinfinity (2300094) | about 10 months ago | (#45137939)

Just get a hold of lex & yaxx, antlr or your favoriate tools and write your own language. You could probabyl abuse Lisp macros anough to do this too.

It seems you are already well underway!

Programmer not the whole story (3, Insightful)

jasnw (1913892) | about 10 months ago | (#45137647)

Yeah, yeah - code clean, test-test-test, document-document-document, have separate test/run machines that are configured the same, yada yada. This is all well and good, and any halfway-decent developer knows all this. However, software development is not done in a vacuum and each and damn near everything mentioned is involved in cost/time benefit analyses when crunch-time comes (which it always does). With some exceptions, when I see a company that's saddled with horrible old legacy codes that nobody can understand, often a large measure of this is paybacks (for not adequate funding and poor schedule planning) being the bitch that they are. How to do things the best way are well known, it's just that the best way is more expensive (in the short term, which is the only term business understands these days) and takes more time than the average business will wait. If the bottom line is get something done that sorta-kinda works as fast/cheap as possible, you get spaghetti code that even the guy/gal who developed it can't follow.

As my predecessor's bumper sticker said... (1)

Anonymous Coward | about 10 months ago | (#45137657)

"Comment? Why do you think they call it 'code' ?"

The real icing on the cake (1)

TheloniousToady (3343045) | about 10 months ago | (#45137681)

Why use "the coolest mix of cutting-edge programming languages" when I can use just COBOL?

There's more than one way to do it (2)

moonwatcher2001 (2710261) | about 10 months ago | (#45137711)

The nastiest project I ever took over was written in Perl by ten diferent programmers eah using diferent features of Perl

Re:There's more than one way to do it: FIXED! (1)

bigredradio (631970) | about 10 months ago | (#45137953)

The nastiest project I ever took over was written in Perl

Re:There's more than one way to do it: FIXED! (1)

boristhespider (1678416) | about 10 months ago | (#45138079)

I love Perl. The only language where I have no idea what I've just written but I do know that somehow it worked and I don't want to mess with it. I know I'm just shit at Perl but even so.

Bad management (5, Insightful)

EmperorOfCanada (1332175) | about 10 months ago | (#45137719)

Often it is how a project is initially managed that results in an unmaintainable system. A few simple mistakes can send a project straight to hell from the very beginning. A simple one would be to allow the senior management to firehose new features at the project far faster than the developers can build them. Another would be to allow the wrong people to pick the core components. That is how bad databases/languages/operating systems can be chosen. Then you get the next layer of wrong when people simply code and architect badly.

An example from my past was a company that I interviewed with (and was offered a job at) that was using Lotus notes to build a huge educational system. They had a PhD as the head of development and they were keeping the details secret until they made their offer. When they told me Lotus Notes I just laughed; I thought they were joking. I told them that building their system out of Lotus Notes was like building a car out of sand and white glue. At first you will quickly have the broad outline of a car but that as you start to work on the hard bits that you will never finish; Ever! A couple of years later the company imploded with no real product just a bunch of sales demos.

Re:Bad management (0)

Anonymous Coward | about 10 months ago | (#45137833)

I'm thinking of mixing in a custom version Scheme where all parens are instead whitespace

Oh god this. I was at a company once where every ... single ... day there was a new hot feature that someone up there had read in a magazine or something and must have, top priority,cancel everything else!!1!one

The code was littered with half-done commented out stubs and UI with buttons that didn't function and features that were going to be implemented real soon now... just as soon as everyone was done with the latest fad (drop everything, we're going mobile!!1!).

But ADHD management isn't the complete worst out there. No, the ones who take the cake are the ones who refuse to accept input and demand things be done their way, and when the thing is built their way, immediately decide that their way was wrong all along and demand that it be reassembled from scratch by the deadline. I was on a UI team like that once.

All Code is Terrible (3, Funny)

TempleOS (3394245) | about 10 months ago | (#45137723)

You will never find good code in a project. All code is awful. Every programmer who looks at a project says it's shit.

Re:All Code is Terrible (1)

Kaenneth (82978) | about 10 months ago | (#45137957)

At first glace, Code is like an unassembled jigsaw puzzle.

Without the reference picture (specs) it's much harder to figure out how it goes together.

Re:All Code is Terrible (2)

phantomfive (622387) | about 10 months ago | (#45138187)

For code, "Structure is the key to understanding." That is the missing thing from many pieces of documentation, an overview that gives the structure of the code. Specs are a good way to get that overview.

Outsource to India or China (0)

Anonymous Coward | about 10 months ago | (#45137735)

That's how.

No such thing as 'unmaintainable' software (2)

johnlcallaway (165670) | about 10 months ago | (#45137749)

Only lazy developers. I've worked on plenty of legacy software over the years that other people wouldn't touch, and the common thread was they were either too lazy or just not smart enough. It takes determination, patience, and a lot of detail to work on it. But it was all far from unmaintainable. And the end result was I was the one kept around during layoffs instead of the guys that said "I can't do it" (translation ... it's too hard for me.)

OK .. no source code at all pretty much makes it difficult to maintain. Or not being sure if what is in use is the current code.

As for the 'use a framework' .. what BS. Frameworks come and go. What is well used today can be a long forgotten, unsupported mess 5 years from now. Like NetBeans and Swing?? All those GUIs I wrote 5 years ago probably now fall into the 'unmaintainable' software category, even though all the code is actually there, and anyone that understands GUI programming at a basic level can still make modifications. It's not easy (i.e. not for the lazy), but it's possible. And how many times has a framework version made upgrading difficult because of extensive changes???

It's OK to use Hibernate, ICE, and all that stuff that makes the job easier today, but learn how stuff actually works and only use it when necessary. It will make you more valuable in the long run, and the code more maintainable in the future. If I hear one more ignorant programmer tells me 'But Hibernate can write SQL that way even if it is more efficient' I'm going to shove a SQL manual up their ass and tell them to actually learn something.

Re:No such thing as 'unmaintainable' software (1)

ranton (36917) | about 10 months ago | (#45137945)

Only lazy developers. I've worked on plenty of legacy software over the years that other people wouldn't touch, and the common thread was they were either too lazy or just not smart enough. It takes determination, patience, and a lot of detail to work on it. But it was all far from unmaintainable.

When someone says that code is unmaintainable, they obviously don't mean that it is impossible to maintain. You can even disassemble binaries if absolutely necessary. If the effort to maintain the code exceeds the benefit of maintaining the code, it has effectively become unmaintainable in any practical sense.

I do agree that maintaining code is more difficult than creating new code, and on top of that it is a less desirable task for most developers. I had to leave one company because they kept putting me projects with legacy software because I performed better on those projects than my peers. They even bumped my pay because they knew it was important. The problem was I didn't want to do it, and finding a new job is easy for anyone with real skills. I wasn't lazy, I just had better options.

If you are someone who likes working with legacy software and are good at it, then you are valuable indeed. Most companies don't have someone like this, so they have to not only worry about the effort to maintain software but also the morale of the developers forced to work on projects with excessive technical debt.

Support Debian's build system, keep Greg employed! (1)

tlambert (566799) | about 10 months ago | (#45137753)

Support Debian's build system, keep Greg employed!

That is all...

I'm guilty of all of these (1)

Anonymous Coward | about 10 months ago | (#45137773)

But I will add another point:

* Manage a software project when you have no experience with software design

The company owner mismanaged the entire thing into the ground and we would often find out that in a few days time, once again, we were expected to have the system working live with the latest feature that we had expressly said was not ready and should not be expected to be ready for months, because he'd already sold it to the people he was smooth-talking to on the basis of that feature.

It was always in a state of permanent putting-out-fires, because as soon as we attempted to contain the ones we had, more would be started for us, because the investors were demanding that some sales were actually achieved for once, which wasn't possible because a year had already been fruitlessly wasted with another cowboy coder that had faked his university degree.

Ugh, what an unfixable mess. I gave it more blood than it was worth - I was contracted into that whole mess late and stuck with it for months - but once my invoice payments started coming in late, I was out, having improved precious little despite my protests.

Worst job of my career. What's worse is that, despite literally everything we told him to do (including cutting his losses) he is still running with the exact same codebase. You literally cannot help someone that refuses to be told that it's over.

... says the self-taught programmer... (3, Insightful)

MasterOfGoingFaster (922862) | about 10 months ago | (#45137799)

Hey, glad I could keep you in business.

He left out "Outsource your project to India" (1)

JoeyRox (2711699) | about 10 months ago | (#45137843)

Not only will the code be a bug-ridden hodgepodge but the comments will be written in unintelligible English as well.

be sure to mess up SQL Server code as well.... (3, Funny)

ClassicASP (1791116) | about 10 months ago | (#45137847)

Use long looong looooooooong stored procedures (20,000+ lines long) with lots of spaghetti SQL code and very little documentation. And never use identities and primary keys; instead just get the max ID number on the fly and use source code to get the next integer-up for the next record insertion to a given table. Make sure the table and field names have almost no relevance to the data they hold. use views liberally, and query one view on top of another view on top of another view on top of another view. If possible try and work something out to where there simply isn't any relational design to the database at all, and instead just use redundancy everywhere. Or, if you really want to be nasty, you could go the opposite route and figure out some kind of a mindbending rubix-cube-like puzzle where there is only one table with only 3 fields in the entire database, and nearly all table data of any sort is stored in one field in that table, and just rely on a myriad of SQL joins to emulate the behavior of relational database design.

Re:be sure to mess up SQL Server code as well.... (0)

Anonymous Coward | about 10 months ago | (#45137931)

Or, if you really want to be nasty, you could go the opposite route and figure out some kind of a mindbending rubix-cube-like puzzle where there is only one table with only 3 fields in the entire database, and nearly all table data of any sort is stored in one field in that table,

I see you've used MongoDB before.

Re:be sure to mess up SQL Server code as well.... (0)

Anonymous Coward | about 10 months ago | (#45138145)

SQL tables? I just store all my data in Excel files.

Re:be sure to mess up SQL Server code as well.... (1)

WaffleMonster (969671) | about 10 months ago | (#45138505)

SQL tables? I just store all my data in Excel files.

Or SharePoint...

Re:be sure to mess up SQL Server code as well.... (0)

Anonymous Coward | about 10 months ago | (#45138205)

Chris, Is that you? I want to thank you for the opportunity to work for a great multi-national organization with flex-time, great benefits and the opportunity to work from home (in the U.S.) 100% of the time. Your shit job, which you were never qualified for, has benefited me immensely. Your knowledge hoarding, spaghetti-code ways may have gotten you fired, but this is a goldmine to a developer with real skills, and the ability to revamp your broken cesspool of development practices. Your name will be cursed forever in this organization except by me - I want to truly thank you!

To Develop Unmaintainable Software... (0)

Anonymous Coward | about 10 months ago | (#45137891)

"use the coolest mix of cutting-edge programming languages."

That's why I program in BASIC and BASH.

He Didn't Delve Into Specifics (4, Interesting)

Greyfox (87712) | about 10 months ago | (#45137983)

How about "Set up a global int l and set it to 0, and a global int O and set it to 1. Or sometimes l, depending on what file you're in." This works better or worse, depending on your font. Or in C++, have every class inherit from every other class. I've seen this done.

A couple times I've run across some jackhole who is in love with dynamic shit and who wants to check java object code into an SQL database and dynamically load it into a program. Nothing quite spells fun like wondering where the hell the code is branching to, and spending two days figuring out it's to an object in a database the code to which has been lost 4 years earlier.

For a long time there in the '90's and a bit later, version control wasn't a normal thing. If you had to get management approval to set one up, that usually would start up the sinking feeling about that job sooner rather than later. Nothing quite like having to justify the addition of something they should have never written a line of code without in the first place. Nevermind trying to get overhead for writing unit tests. Assuming unit tests are even possible. For most of the projects I've run across, the coupling is so tight there's no way to get in and test discrete functionality of anything.

For the guys not using version control, "Lose the source code" is a good one. You don't even have to be malicious about it (Though malice helps.) Just build the thing on your personal dev box, deploy the executables to production and never mention it when you leave. Bonus points if they walk you out during a layoff.

"Don't set up a build system" is another good one. Gotta love those projects where you have to run a top-level build three times before it produces an executable!

Re:He Didn't Delve Into Specifics (1)

DoubleJ1024 (1287512) | about 10 months ago | (#45138109)

This almost sounds like my previous employer. The software group had version control, but the electrical and mechanical group did not get anything until right before I was laid-off. It was fun being the department librarian and having to keep track of random files that the only real difference was the date stamp. I finally got the electrical group under control, the mechanical group had a completely different system that would ONLY interface with Solidworks, the software group used one of the microsoft version control systems, and we in the electrical group used SVN. What a fun challenge to maintain and organize. Thankfully I don't have to deal with that anymore, our files at my current employer are nothing more than word documents that ANYONE can modify. I have tried to get them to learn about version control but telling a large defense contractor about something simple like SVN is a lost cause.

Re:He Didn't Delve Into Specifics (2)

Greyfox (87712) | about 10 months ago | (#45138217)

Really? Try pointing out that document revision control is mandatory under the ISO 9000 process. That should get the ball rolling pretty quickly. Or A ball, anyway.

Job security (0)

Anonymous Coward | about 10 months ago | (#45138035)

In the current economic climate of outsourcing that's what any sane programmer should do. Good piece of advice!

Terrible is a matter of perspective (1)

xtal (49134) | about 10 months ago | (#45138053)

Terrible for the client, maybe.

Terrible for the job security? Maybe not, under the right circumstances. Not everyone has lawyers to negotiate fat maintenance contracts.

Doesn't make it right, but just saying.

Comments Should Restate the Code and Add Nothing (0)

Anonymous Coward | about 10 months ago | (#45138061)

As in:

rem This is a loop!
For i=1 to 20 Do

Then Quit in a Huff When it's Only 2/3 Finished. (2)

rueger (210566) | about 10 months ago | (#45138077)

At one organization I inherited a fund-raising database developed with much arrogance in Filemaker Pro. Except that the FMP "Guru" quit in a huff when it was only about 2/3 functional.

Despite this the thing was used - with many, many crashes - for two years because it was the best thing that they had. And because Mr. Guru was a pal of half the staff.

Did I mention that Mr. Guru also refused to hand over any of the logins that would allow someone to fix or administer this thing?

We eventually wound up moving over to MS Access (GOD YUCK EVIL!), and massaging, fixing, cleaning, importing ten years of data, each year on a different format, file type, or with different fields. We actually managed to turn it into a reasonably useful fund raising tool. I mean, aside from the downside of using MS Access.

Documentation? HA HA HA HA!
Instead we had lots of on-screen buttons though that didn't do anything because he never quite got around to it.

Using new technologies (1)

CanadianMacFan (1900244) | about 10 months ago | (#45138107)

I once was working on a project that included a bunch of dependencies because the original developers wanted to learn the technologies like an expert system. The program didn't need one but they threw one in anyways because it would look good on the resume.

Re:Using new technologies (1)

ZombieBraintrust (1685608) | about 10 months ago | (#45138537)

I was on a project where architect had read a book on Spring. This was 7 years into the project. We had a screen that needed some new edits. So he had us refactor the old procedural code into tiny classes that were contructed using xml config files. We also used Spring annotations, because he finished the book half way through the update. 6 months later the architect is promoted. 9 months later I training a new developer.

I have looked for a few days and can't find the code that validates date of birth is before current date?

Ohh sorry, you see there this xml file that controls how these generic classes are instanciated. These beans are collected as a list and depending on blah blah blah...

Not Useful (1)

SerenelyHotPest (2970223) | about 10 months ago | (#45138167)

I already know how to write unmaintainable software. This hardly needs to be written about. If there were a good list of practices for writing maintainable software, that might be more constructive.

Prerequisite (0)

Anonymous Coward | about 10 months ago | (#45138209)

Aren't all the aforementioned attributes actually listed as requirements in government work?

Also be sure to use OS tools (0)

Anonymous Coward | about 10 months ago | (#45138281)

Use random untested programs. preferrably obscure ones from github with no forks or bug issues. For instance, don't the language's search methods, instead make a call to use the system's grep. But not the actual grep command, but a modified one - like grep-contrib. Which in turn needs to be compiled with a custom compiler, gcc-contrib.

and obviously, dont document any if this. make the next poor soul look at the code and find out.

Also be sure to use OS tools (1)

katsh (2760437) | about 10 months ago | (#45138291)

Use random untested programs. preferrably obscure ones from github with no forks or bug issues. For instance, don't the language's search methods, instead make a call to use the system's grep. But not the actual grep command, but a modified one - like grep-contrib. Which in turn needs to be compiled with a custom compiler, gcc-contrib. and obviously, dont document any if this. make the next poor soul look at the code and find out.

Why no "invent your own language"? (0)

Anonymous Coward | about 10 months ago | (#45138315)

I worked for a certain company where their entire point of sale system was written in some obscure dialect of BASIC. It ran under some antiquated version of SCO Unix, and you needed to use a terminal encoding that only one or two terminal emulators actually spoke just to interface with it.

I think it was written at a university or something, I'm not sure. What I do know is that there was basically one guy in the entire city who still had the original source code tapes and could actually do anything with the code. The actual BASIC source code was pretty much 100% undocumented and almost completely unreadable. I've never seen anything like it, but that guy was in almost every week being paid some exorbitant amount of money as a "consultant" just to keep the system from collapsing in on itself.

They were working on a replacement (I question how dedicated the BASIC guy was to this task), but a few years after I got the hell out of there I walked into one of their stores and noted the same old terminal emulator, interfacing to the same tired SCO Unix system running that same old BASIC crap. Absolutely nothing had changed.

So really, if you want to insure your job for the immediate and far out future- write your own language. Use a whacky intermediary bytecode format, keep the compilers to yourself and deploy the interpreters/VM to production. This is pretty much the ultimate way to tie yourself to a system, and if you do it right you'll make boatloads of cash practically forever.

Documentation is overrated (2)

140Mandak262Jamuna (970587) | about 10 months ago | (#45138389)

Documentation goes out of synch with the code very quickly. The only thing worse than working on someone else's code without documentation is working on someone else's code with incorrect documentation. The problem is so old Dijkstra allegedly said, "Always debug code, not the comments".

Oh, yeah someone will tell me I am doing documentation wrong. How come "you are not doing agile right" is a valid response but "you are not doing watefall right" is not?

I know the guys to ask (1)

ddd0004 (1984672) | about 10 months ago | (#45138421)

The guys who wrote the software at my previous job were masters of it. I don't know all their secrets, but some of their finest work included: single character named global variables that were reused indiscriminately, code in stored in a database that was then evaluated inline that did things like changing variable values and declaring functions and other fun stuff, 500+ line functions that tried to do a little of everything, and liberal use of copy and paste.

The best language for unmainatinability (0)

rssrss (686344) | about 10 months ago | (#45138531)

brainfuck [wikipedia.org]

Nothing wrong with writing from scratch (2)

FuzzNugget (2840687) | about 10 months ago | (#45138673)

As long as you document, label and organize your code coherently and logically in a solid language, coding from scratch (or near scratch using libraries of your own) can be a good thing. It avoids pitfalls like vulnerabilities that affect common code bases, massive libraries that take friggin' *ages* to load on an i7 with a fast internet connection or relying on the developer(s) of library X to add feature Y ("sorry, we can't add that feature yet Mr. Client, it's uh ... because of complicated programming reasons, basically, we're relying on a third party and we don't know how to do it ourselves")

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>