Hard Problems

[Anonymous Monk]

As I see, with knowledge of Perl and CPAN Modules and some sort of expertness, solving any problem is just an engineering problem, where you just have to put the pieces together and create a flow. But often times, I see some hard problems. What are those according to you?

• Huge Amount of Data
• Large Processing Time
• Different versions of Perl/OS
• Non-centralized data
• Unknown hardware failure
• Segmentation fault (out of memory)
• Lost code :-)
• Lack of code maintenance due to a left developer
• Unmaintainable code due to spaghetti nature

[Bloodnok]

Lack of code maintenance due to a left developer

I've, all too frequently, found that right developers can be a cause of lack of code maintenance as well :-D

More often than not, the responsibility for code maintainability (or lack of it) can be laid at the door of poor/missing coding standards &/or conventions when code is authored.

One of the biggest, most widely recognised, programming problems is the means by which (quasi) real-time behaviours of the system (and thus capabilities of the code) are modelled, handled, implemented & subsequently, properly/comprehensively tested.

[Tanktalus]

Personally, I've found that lack of code maintainability is multi-faceted, though I think any one of these could be causes all by themselves:

• A focus on delivery over correctness. Managers too focused on the immediate, with no foresight relating to Technical Debt.
• A focus on cheap delivery over a well-thought-out design. This is related to the previous item. What's the cheapest way to get this out the door now?
• A focus on minimal code to delivery over preparedness for last-minute changes you know will come up (even if you don't know the specifics). Robust, flexible code is not a priority.
• An unwillingness of the developers to overcome the above.
• A lack of repercussions in developing bad code. This probably is a partial cause of the previous item.
About three years ago, I switched into a focus on code-in-the-field support over next-big-thing development. Which means I've had a couple of full releases "thrown over the wall" at me any my team to maintain and perform problem-resolution on with paying customers, while they go on with less knowledge than ever about what customers are actually doing with our code. I don't have time to educate them on every issue that comes up, and, besides, experience is the best teacher, while I would be a distant second. (Well, if you only have two options, I'd be the distant second. Add more options, and I fall in the rankings fast.) When I was doing the next-big-thing development, I would always, even when management wanted something else, do a Scottie-style estimate: double and add one / round up, regardless of units. Something that a coworker would size at 3 days, I would size at two weeks (3x2+1 = 7 working days, round up to two weeks). My co-worker would get an unmaintainable mess at the end of four to five days, yet I'd have something maintainable and flexible in three to six days. It was a focus of mine because I knew that the fewer problems that customers had, the less they'd call for support. The less they call for support, the less that the customer support people would bug me. The less they bug me, the more work I could get done. The more work I get done, the better my year-end review, and thus the better my raise/bonus. It was all about the cash. I don't quite get why my coworkers missed this.

Meanwhile, now that we've split the responsibilities, there is no negative repercussions, no negative feedback to the original developers. They code in a vacuum. And quality has gone to $#!+.

But that's just my take on it. I'm so looking forward to moving to another team that does both next-big-thing development AND development-support of in-the-field code, hopefully by the end of the month if all goes well.

[Bloodnok]

I would add the following to your list of causes (of bad/unmaintainable code):

All too frequently, prototype/POC code (never destined to be maintainable in the long-term) is delivered as a fait accomplit - instead of code engineered on the back of the results of the prototype/POC process.

All in all, methinx this (c/w your observations) can all be summarised using the age old maxim/adage:

We can always afford to do it [develop the code] wrong many times, but seemingly we can't afford to do it right first time

[JavaFan]

All of them can be a problem, none of them have to be a big problem.

I guess I fail to see the question or the point you're trying to make. Do we have to make a pick from the list to guess what you see as hard problems?

[Anonymous Monk]

I think you can take them as examples, and list some hard problems according to you.

[ack]

All of those represent a good cross-section of challenges that always seem to make me think "this is a *really* hard challenge!"

One other that, at least for me, is inevitably "hard" is when I'm presented with complicated data content in a file(s) that just won't yield to straightforward information extraction. They usually have a distinct lack of tags or many different "keywords" for specific items; they usually have lots of numbers intermixed with lots of miscellaneious text.

Of course, this is where Perl shines...it is, afterall, a superb data extraction language. But inevitably, I have large mixtures of parsing, string manipulations, and regexs that seem to be convoluted and difficult to keep straight. I suspect a lot of the challenge comes from being insufficiently adept and experienced with Perl and it's multitude of capabilities.

But whatever the cause, information extraction from complicated source data structures always seems to be nightmarish for me.

[Xiong]

Hands down, the most difficult problem I encounter is lack of a customer (or customer proxy) available to give feedback on the project. Without a consumer, stakeholder, or whattayacallem to compare the solution to the demand, it's difficult to say when the project is headed in the right direction, let alone when it's done.