- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
It all sounds like what happens when you let someone loose on Aspect-Oriented Programming who doesn't have the good taste to know when to not use it. WaTerFagile indeed…
Admin
Sometimes, what you should do is replace an ill-conceived, under-designed existing application with a more flexible redesign based on your current scope, which is drastically more complex than it was when you began.
Admin
Too much bad code comes from over-eager developers wanting to use something that has no place in what they are developing.
Admin
"Fagile" - it's Italian!
Admin
And among those obstacles, the most relevant one is the ground...
Admin
Ho-hum, normal day at the office, nothing to see here, folks, move along now...
CAPTCHA : genitus - A.W. doubled over in agony after his suddenly-former girlfriend kicked him in the genitus...
Admin
Learning to fly is easy. You just have to develop the knack for throwing yourself at the ground, and mising...
CAPTCHA : haero - don't try to be a haero...
Admin
Admin
Snoofle should undergo a rewrite. Spoken language isn't the same as written language.
Admin
The only time I have ever seen a valid reason for a rewrite is when you are porting an entire application from e.g. FORTRAN on a VAX to e.g. C or Java on a Windows/Linux environment, implementing a browser front-end.
In such cases you do well to implement it incrementally, porting it over a module at a time, ensuring you get exactly the same results on the new installation that you do on the original one. Any differences should be caused by bugs in the original version which were hitherto undetected. In a perfect world, those bugs should first be implemented in the new system, and then when the results do match precisely, only then do you implement the bug-free version on the new version.
The argument "This code is a pile of rubbish, let's throw it all away and start again from scratch" is just so wrong it's become a standing joke in the industry. There is no program which cannot be improved by incremental refactoring, merely lazy, incompetent and/or prima-donna programmers who believe such tasks as either demeaning or unappealing.
Admin
Admin
The real-world example that I have in mind is a site that I'm working on for a club that I belong to (i.e., for free).
It's over a decade old, written in a mixture of Perl and PHP using a text file for a database. I've learned Perl and used by PHP skills from college to help clean up the worst parts of it, but not go overboard.
It's bad enough that all of the forms use GET instead of POST. So I'm replacing all of the Perl and PHP scripts with Python, but simple. Something better than long, standalone scripts, making sure that anything that works with the database (aka text file) is in one place, so that after I update the entire front end to use Python, I can then replace the text file with MySQL, and it doesn't take much to do the upgrade. I won't need to change the Python scripts except for the actual data access ones.
So after I upgrade the site to Python, but before the MySQL upgrade, the site won't work much differently other than simple things like using POST instead of GET.
Once I get the site to use cleaner scripts, then I can upgrade it to use a real database, and things like jQuery.
However, since I'm my own boss, this is the best case scenario, so it's unlikely that you'll get this level of control in a professional work environment. But in a development utopia, you'd be able to replace what you need to with code that works the same, but is much easier to upgrade, then make those upgrades in a later phase.
Admin
Why then do demolition companies exist? Can't any building be adapted to the desired purpose of the lot, save for the lazy/incompetent people in charge?
The ultimate reason why "nothing" can be a better starting point than "something" is this: It's far more effective to read your own mind than to read someone else's.
Admin
Not since the rebel attack on the death star.
Admin
Admin
That was a common practice back when I started (early 1970's) and was almost universal a decade earlier when my mentors started their careers.
You received an immutable and unquestionable (nobody to ask) specification, and delivered that. Eventually it would get tested, and a few months later you would get a new version of the specification along with a list of "deviations" which you addressed.
I remember all too well a specification that contained "when age is 18+ OR under 25" (it should have said AND). The code was written (it executed for everyone, and the other conditions never did). Six months later the code was completed (about 3 man years of work), and submitted for testing. Nearly 9 months after that we got back a "failure" as part of the deviation report. We completed another 6 month cycle which contained justification (quoting the exact specification). They tested, it still was wrong, and more than 6 months later a revised specification (with "AND") was received (along with other changes) and another cycle began.
Almost 3 years of delay that today (Even with CMMI) would be handled in a very short time (and nobody would proceed with writing the known wrong code).
Admin
Because when you do a good job, your WTF boss will fire you.
Admin
Any program can be gradually made better. There is a methodology that any time you change something in the code, you refactor nearby code as well so the resulting codebase will be better in overall than before. This only works if the code has decent unit tests, otherwise the risk to break something is too large.
It may sometimes happen indeed that a complete rewrite would be cheaper, but without tests or specifications you will never know if or when the rewrite is finished, so this claim cannot be really proved. And if your codebase already has tests and specifications, then a rewrite is typically not needed.
Admin
'...dial down the lunacy...'
In other words they couldn't be bothered doing their jobs so decided instead to define the task out of existence. Nice work if you can get it.
Admin
Admin
Yeah, I rock the boat a lot less at work. Although the managers in my department very strongly support us programmers, so I have that going for me, which is nice.
Admin
This is EXACTLY what 90% of organisations perceive "Agile" as. They never work out actual capacity, they do full project plans and simply break it down.
Most Business Units won't fund something if they don't know what they're going to get, so you have to compromise and work it out. Of course, the compromise doesn't stop there: nothing is prioritised and everything is in. They use scrum to manage day-to-day operations but forget about the business.
Quite honestly, the only people who really can implement true Agile practices are IT companies where the developers ARE the business and everyone understands what is going on. It will never change because IT is underappreciated and treated with great skepticism (usually for very good reason).
The customer IS ALWAYS RIGHT, except when they're wrong but even they're right.