- 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
weird, very weird
Admin
wtf, why did he use a database?!?!
Admin
I'm speechless.[:|]
Admin
Deep sigh. WTF! [8-)] I wish I was that idiotic and made huge amounts of money.
Admin
In the famous words of Bill the Cat: "Ack!" With full-metal accompaniment by the Boingers.
Admin
It's a security feature. You can't supply a URL with an invalid type because it's not on the list in the database.
Admin
You might be joking but in case you are not, these were parameters passed on the URL. The Strings (with spaces) were already in the DB is a uber-parent table. This was merely a 'solution' to not being able to put spaces in URLs.
Admin
Now wouldn't you prefer that this guy be employed developing websites rather than in aCivil Engineering position.
The cost is justified by the need.
Admin
This is a classic WTF IMHO.
Here you've got a situation where a 'programmer' is under the impression that he's the only person that has ever needed to pass values that contain spaces from one web page to another so there can't be a URL encode/decode function built-in since no one else has ever needed to do what he's doing.[:|]
If he thought about it for 2 seconds he should determine that this has got to be a common occurrence and that there must be a standard was to do it.
As my dad would say "Use your head for more than a hat rack"
The database usage is just icing on the cake.
Admin
lol - I actually have a Billy and the Boingers 45...it came with one of the comic collections. - Damn...am I dating myself talking about 45's?!?[:#]
Admin
Heck... He would have to have even thought about it. All he would have had to do is what most of us do instead of thinking about a problem ---- Run a Google search! (and then look at the URL.....)
Admin
He wasn't stupid. He graduated from one of the top 4 engineering programs in the nation. He just had no experience in software development, not even in school. He bragged about how he had never taken a class in programming. Knowing what I know now, I should have replied, "it shows." He probably would have been good at building bridges since that's what he studied.
This is so common in my experience. 'Smart' kids with no expereience are put on new development projects. I don't care how smart you are, you need to do some maintenance before you design and code new systems. There's no way to know the pitfalls without experiencing them yourself. So, even though it pissed me off when I started, doing maintenance was one of the best things I ever did.
There seems to be some sort of commonly held fallacy in IT management that you have maintenance developers and new code developers and that they are completely different skill sets.
Admin
OMFG,James,Ican'tbelieveyoupostedmycode.
Admin
There is much wisdom in these words.
At worst, you wind up with a development staff that is so tired of all the mistakes of their predecessors, that they'll think twice before repeating them. At best, you have a group that will think twice before opting *not* to write unittests, documentation, and put in the extra effort for a good design.
To do otherwise is a workplace antipattern if I've ever seen one, and probably contributes to 100% of the article content of this site. ;)
Admin
I ran into a similar problem a few years ago.
A Company had a successful DOS-based product. They wanted to port it to Windows. So, they put their best programmers to start the project, while they began to hire developers with Windows experience. (I joined as one of the latter). As the Windows team was built up, the original team members were either transfer back to their previous departmentd, or left the company.
Sound reasonable?
The problem was, the people who designed the basic architecture of the new system, knew little about Windows, while the people who had to implement the company's business logic on top of that (flawed) architecture knew nothing about that business logic.....
The final system barely ran and barely integrated with the existing system.
Admin
Wow. Never in a hundred years could I even make up a story like that. Does that make me a good programmer or a bad one? :)
That falls into the category of being "overly clever" in my opinion.
Admin
I'm betting this guy's an Oracle consultant nowadays. [:p]
Admin
Well, it's not like anybody else would date you.
(stolen from a Dilbert strip, but I couldn't resist)
Admin
Perhaps this highly-paid consultant has developed a database that performs queries faster than a URL can be encoded.
Before anyone asks: yes, I'm joking [;)]
Admin
But this way, not only is he a web developer, he's also a database guy!
Admin
Actually I am one of those people who is at his best when developing new stuff for his company. I love figuring out how 'new' stuff works, and making all the mistakes and learning from them. If there's no one to do that, then there's no progress within the company, is there?
Drak
Admin
is this a bug or a typ on the wtf?
the space is in the right colum there
Admin
I'n new here, and first of all, I would like to say that this website is truely great. I learned so may new tips, tricks and programming patterns. Hardly a day goes by without using one of them >:)
For the defence of the poor civil engeneer: A Computer Science degree doesn't say that you can code any better that without one: I know that most of my old colleage student can't code any better that the poor guy right here. I remember a project with five other students where I ended up designing the whole app, and telling the others what to do, and eventually ending up rewriting they code, because thet still couldn't do it right, even when I gave them the easyest parts ;)
You learn coding by doing, learning and having fun, not just bij learing! Stragly thouse colleages did get good grades for theit graduation projects. Well, I guess they had lots of fun, or (what is more likely), the teachers were just as bad in coding as they were.
Admin
Laugh all you like, but remember. The guy who came up with this "ingenious" ID managed to get paid for it and probably got paid well too. And why? Because he was a genius? Nope, simply because he had a piece of paper (diploma) that told everyone that he's supposed to be a genius...
Geniously stupid, yes...
Admin
Well, then of cource, you have the master of stupid people with high paying jobs: Geoge Bush :)
Admin
I think that he needed 2-way encoding/decoding. Later on in the DB will probably be the '75 LOC' -> '75LOC' conversion.
Admin
Boy, I walked into that one.[:P]
Admin
That is quite a substantive point. I had the experience of being a "new dev" guy right out of college; but I was fortunate to suffer through the entire life-cycle of my first product, so my own early decisions came back to haunt me.
I don't, however, necessarily think maintenance is the best route--organizations need new development, and it helps to have the "go-getters" on them. From my own experience, I'd suggest mentoring the kids--having someone experienced look over their shoulder for a while before they're cut loose. And the kids should be shielded from management "oohing" and "aahing" over their supposed intelligence.
For instance--when a "smart" kid writes something like this, the mentor will be there to slap him over the head with the nearest blunt object. What better kind of "conditioned response" learning could there be? [:)]
Admin
This isn't an actual DB table. It's just some text I typed up to demonstrate the concept. An error on my part.
Admin
You said yourself that your decisions cam back to haunt you. We all have that experience no matter how experienced we become but by the time I started doing large scale new development, I had already had 2 years study in what not to do. I learned a lot about what worked well and what was really difficult to maintain. My first new development (and re-design) tasks went off quite well and stayed well over time. This definitely would not have been the case if I was put on new development right off the bat.
This is the exact philosophy I do not understand. If you are having a house built, would you want an experienced architect and contractor or a couple kids on their first job designing and running the show? If you were getting a heart transplant, would you want a doctor with years of experience or an intern as your surgeon? I don't understand why inexperience and lack of familiarity is seen as a virtue in software development. I understand that sometimes older developers get stuck in their ways but that's why they should work with the new blood so they can learn from each other.
As far as go-getters, I think people who have to work their way up are much more likely to be real go-getters than those who have everything set in their lap.
This process also implies that more experienced developers will be moved off new development into maintenance over time. This is terrible for morale and you tend to lose your subject matter experts.
Admin
One of my physics professors used to like to say that smart people learn from their mistakes but really smart people learn from the mistakes of others.
Almost all advancements in human history have been built upon the acheviements of others. What value do you provide by reinventing the wheel?
If we followed this philosophy in physics or any other natural science, we'd have very little progress. If Newton had ignored the discoveries of Galileo, Kepler and Copernicus, he wouldn't have been about to some up with his theory of gravity.
How can a developer be expected to write maintainable code if he or she knows nothing about code maintenance?
Admin
Maybe that's why engineers are required to have a license.
II am certain that if the bottom 50% of programmers were to suddenly disappear, total industry productivity and quality would double.
Admin
Sounds like we got us a terrorist here... Perhaps a Caribbean vacation in beautiful Guantanamo Bay is in order.
Admin
And once again we have an example of "Why Engineers Shouldn't Be Programmers..."
Admin
My experience is that my second new development project was exponentially easier to maintain. First-hand pain is a wonderful teacher; and being a little conscientious goes a long ways.
I disagree with the premise of your question, because you're assuming that experience is wholly quantitative in nature. It is very possible--in this field, especially--to get "one year of experience five times" instead of "five years of experience."
Furthermore, you're just giving me a false dichotomy: "would you rather have some wise sage, or an inexperienced brat?" I'd rather have neither; I want a mixture of innate smarts and some--but not necessarily a decade of--good, hard-earned experience.
Your question, by the way, also reveals another facet of the discussion: a great surgeon with many years of experience is very expensive. He is probably paid very well--and as the customer, I would (in theory) pay accordingly. The same goes for many professional services. So you're not even considering the economics of the matter.
I don't think the industry values youth and inexperience; the industry values people who learn quickly and don't make the same mistake twice. And many businesses will try to find younger people who fit this bill because they cost very much less (and are easier to find) than someone similar with ten years of paper experience.
Admin
But why is it neccesary to write the first (bad) piece od software? Why not gain the maintenance experience first.
But the point is that in reality that it is generally known whether a given developer has more relevant experience than another and the less experienced developer is chosen. For example, a developer with no experience vs. developers on the team for several years. This exact situation resulted in a developer with no experience being chosen over the experienced developer. Not only did this result a lot of bad code, most of the experienced developers quit. How is that a good management strategy?
Actually it's not false. It's precisely analogous to the situation I am referring to. Right now I see contractors with 0 years expierience developing an new system. It's hundreds of thousands of dollars over budget and years over-due. I don't see why it was done that way yet you seem to be implying that it's a good way to do things.
No I am specifically speaking of the situation where all the developers are already on the payroll.
You've misunderstood my point. I'm not talking about hiring practices. I'm talking about how resources (developers) are used. I see a lot of software designed and written by developers with no real world experience while experienced developers are doing the maintenance. This is a back-assward strategy IMO.
Admin
SAS, About your Avatar...
Are you sure that you're not a high paid Oracle consultant?
P.S. Love your suit!
Admin
I didn't say it was. In fact I explicitly said it wasn't. I think the first project (or a significant part of it) for a (bright) new developer done on new development should be done with close mentoring from experienced people, so that it's _not_ a train wreck.
It's not--I think the assertion I have a problem with is the idea that new developers _must_ do maintenance programming before going on to new development; which is not to say they should just be rampantly "cut loose." See my previous point. [:)]
It certainly is--I just have a problem with the idea that new people can or should work exclusively on maintenance for a while prior to pursuing new development.
Writing maintainable code isn't rocket science. It is a transferrable skill. But the skill actually has to be transferred somehow; and I personally would opt for a "mentoring" strategy.
Admin
Well I think we are in agreement. I am not saying that any developer should work exclusively on either maintenance or new development. All members of the team should generally work on both.
However, before a developer is allowed to design and code a subsystem from scratch, they'd better have a good bit of experience changing old code. Developers who have had to work with older code are going to tend to be more considerate when creating new code.
Admin
<FONT face=Arial><FONT size=2>In my experience no developer should ever be 'cut loose’; traditionally hierarchies (Steering Committee -> Technical Architect -> Senior / Lead Developers -> Developers) exist for a very good reason. The senior / lead developers design components, do a bit of development work and review code; the developers realize the designs into code. There are plenty of methodologies out there to ensure developers stay on track and all work is traceable right back to the original Business Requirements. <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></FONT></FONT>
<FONT face=Arial><FONT size=2>In my experience projects which follow a good chain of accountability with good traceable documentation (Use cases, blah blah, blah) rarely have a monstrous WTF glaring out, by that I mean no huge design WTFs, sure some smaller WTFs get though the review process (ingenious and interesting ways to round numbers, and dates seem common place) but the biggies which would take weeks to design out tend to be caught on the white board or the fag packet sketch. When these methodologies and project hierarchies are deviated from, the project becomes much akin to sticking a load of brick layers and plumbers on site and asking them to build a house…. <o:p></o:p></FONT></FONT>
<FONT face=Arial><FONT size=2>Then again, this all assumes you have good architects and lead / senior developers; it does seem common place to promote anyone with 5 years or more experience to the next ‘level’… regardless of ability. And I have come across some technical architects with no expertise in the given language (Some business seem to think that architects do not need hands on experience with the technology being used, I’ve come across Java architects with no .net experience working on .net projects).. Even worse I have worked with an architect who came from the analysis / business side of things and had never actually developed (he thought reading a book on design patterns was a sufficient..<o:p></o:p></FONT></FONT>
Admin
Proper attire is crucial to effective (high-paid) consulting. See here. :-)
I don't think insert link is working. Here it is: http://www.dba-oracle.com/dress_code.htm
Admin
And who allows spaces in parameters (or keys) that need to be passed anyway? ;-)
Admin
Have you worked for any small companies or start-ups? It's practically a necessity there; they rarely have the resources to implement the process-oriented environment you describe.
But honestly--the "methodology" atmosphere does breed the "get everything right to the Nth degree" mentality--"righter than right"--that is so characteristic of lethargic, big companies. And I think that kind of top-down structure is basically there to smooth out differences in ability.
I do think it's a good place for young developers to "cut their teeth."
But the economy needs a balance of process-oriented development--particularly for more "mature" products--and "cut loose" development--especially in start-ups. I would argue that the latter often feeds the former; many big software companies were started in someone's basement...
Admin
Absolutely true. There's a large difference between Computer Science, Computer Engineering, and "Software Engineering". CS and CE provide building blocks, but very little instruction or guidance on how best to put them together to create a product which meets customer requirements while also being easily testable, maintainable, understandable, and sufficiently flexible to adapt to the inevitable changes in requirements. Optimal techniques for achieving these goals are not at all obvious and certainly never taught in undergraduate courses in any discipline that I've heard of. Unfortunately the skills involved in this sort of state-of-the-art software development are under-appreciated and almost never examined in interviews or performance reviews. Even Microsoft's interview process, one of the more grueling in the industry, does not (at least when I went through it ten years ago) cover most of these goals.
Some (usually small) companies recognize the importance of these higher-level goals of commercial software, but most do not. Could this be one of the reasons why most commercial software and a lot of F/OSS is crap? We see a lot of crap here, but I suspect that this web site is barely scratching the surface. One of my favourite quotes by a co-worker, slightly paraphrased, is "What are you complaining about? It compiles and runs, doesn't it?"
Admin
At the risk of being labeled a troll, I would have to say that Computer Engineers make better programmers than Computer Scientists. Why? Because Computer Engineers (at least at UIUC) have to take more math courses, and actually have to understand computer architecture before they can even delve into the advanced stuff like VLSI. They also have to understand what a compiler *does* to optimise code (loop unrolling, branch prediction, etc). Computer Engineers also have to learn assembly code. While one the one hand a CS major would understand OS programming and probably AI and a CE would not, the CE would understand the fundamentals behind programming languages, compilers, and WTF the language and compilers are doing in the background. Also with a better math and physics background, a CE is less likely to screw up a piece of analytical software than a CS major.
And unfortunately, I have never seen a degree called "Software Engineering". That has to be learned the hard way, though you can simulate the experience at the university by being a leader in group software project. Basically, if you don't organize your code not at least make it legible, chances are your project will never get done or suck [something unpleasant].
Admin
I hear this all the time but it's not my experience. Computer Engineers tend to be too far down in the weeds. I don't think many CE degrees focus on Object Oriented Programming or high level languages.
Any good CS program should have computer architecture as a requirement. Mine did.
I don't know what you think CS is but it includes all this.
Most programmers use little math. Most programmers need to study discrete mathematics and this should be part of a Computer Science curriculum.
CS curiculum should include (at the least) data strucutres and algortithms, computer architecture, languages (compilers parsers etc.) discrete mathematics, and networking. All of these are pertinent to development.
It exists as a branch of CS. Generally it's graduate level.
The reason that CS degrees are often not respected is that it is often too easy to get into the program and too easy to get the degree. A lot of people go into the programs looking to be hackers, not to really study computer science. That doesn't mean CS isn't valuable. It just means there needs to be a graduate level software engineering major for those looking to just become developers and not computer scientists.
Admin
A CE or CS degree does not make a good programmer. Some of my favorite posts here are from the wundertwins: a computer science masters degree from a top notch school and another guy with a doctorate in computer science. They came up with incredibly brilliant ways to solve "problems" (like this one, and many of the early posts on the site). They were absolutely terrible programmers, yet both were in the top of their classes.
What a CE/CS degree does get you is good perspective on solving and understanding real-problems problems. I've used concepts from my compiler design class more times than I would have ever guessed.
More "bread & butter" topics: Operating Systems, Relational Theory, Compiler Design, Structured Systems Analysis & Design.
I don't believe you can learn that in school. Most college kids have a hard time even envisioning what life would be like in cubeville. That's what internships, first jobs, and mentors are for.
Admin
I've worked with many computer-engineers-become-programmers. On the whole I don't think your assertion is at all true--they tend to be very good at solving individual problems, but not so good at "developing"--that is the whole process from start-to-finish, including design and "big picture" stuff (not just architecture, but business perception).
That's not to typecast--I don't think anyone fresh out of school is likely to have the depth required to do a professional job. But the deficiencies are certainly there; and on a comparative basis, I think the Computer Science grads are starting farther along in the game.
Admin
It's particularly a necessity when working with limited resources, it doesn’t take long to think up a design (i pray that people think before coding) update a diagram and run it past someone for a sanity check. All in all, a smallish sub component shouldn't take more than a few hours for a decent high level design.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>
When resources are tight, getting it right first time is really important (well it's always important, but in small teams it's the difference between staying alive or going bust). There is nothing wrong with 'XP' or 'Agile' development methodologies, as long as design and unit testing take place. My gripe is the growing tendency for many proven methodologies to see a project from requirement to roll out are being totally ripped up and the label 'Agile' or 'Extreme'/ 'Xp' are being slapped on them, when those methodologies actually do advocate the use of relevant processes. <o:p></o:p>
Anyway, my rambling point is, if you have 3/4 + developers on a project, you need some form of process and control on the project, otherwise days wasted 'refactoring' lie ahead, which cannot be afforded with limited resources and be avoided with high level component design, and utilizing unit testing tools. <o:p></o:p>
I agree that some places do go overboard on process, I’ve come across several project in which the client has been demanding exhaustive, class, static, activity (etc etc) for every component... all this did was cause a huge bottleneck on the design team. In my opinion component design documentation should only really depict the main public interfaces... Showing all the private classes, method overloads and private fields just get in the way.<o:p></o:p>
Admin
Actually, one of the major concepts in engineering is a top-down approach to problems, but yes, the "business factor" is often ingored. Especially since the focus on projects is entirely research based, with no particular emphasis on whether or not it is financially feasible. Of course, this is probably because UIUC is a research university. On the other hand, a friend who went to Illinois Institute of Technology for CE had to pitch a couple projects with business in mind.