• LCrawford (unregistered)

    Console.WriteLine IsNum("Frist");

    ... false

    The function should actually have been named IsPositiveIntegerOrZeroLessThanOrEqualToTenToTheTenth

  • GreyHatHarry (unregistered)

    Thanks for submitting your WTF, Karl! Now, flagellate yourself with some spare CAT5 cable as penance.

  • (nodebb)

    I honestly hate how often businesses are clueless about technical debt. They're always too focused on new features (which are often not even needed) rather than making sure their code can be modified and fixed when bugs inevitably crop up. You would think after several decades of this people would finally get a clue, or at least IT management would have enough balls and communication skills to explain to the business why this is necessary instead of almost 100% of the time kowtowing to them and ruining things for their teams later.

  • Ryan of Tinellb (unregistered)

    I want to see the one that checks if a number is hexadecimal.

  • Very Very Expensive Enterprise Consultant (unregistered)

    Well done, carry on the good work!

  • Craig (unregistered)

    That would be Int32.TryParse (or perhaps int.TryParse using the built-in C# alias), not Integer.TryParse, which won't compile.

  • kktkkr (unregistered)

    Of course, if you're only looking at O(n) complexity this is actually not too bad.

  • Kleyguerth (github) in reply to DocMonster

    The standard excuse for that is "there won't be bugs to fix if we are kicked out of the market for not delivering features when people want it". Makes sense for startups, not so much for huge companies

  • P (unregistered)

    Regarding "throwing more bodies at the project" the PHBs have clearly also not had chance to read "The Mythical Man-Month". It was only published very recently (in 1975). Too much wasting developer's time to do since then...

  • Raj (unregistered) in reply to Kleyguerth

    I think the whole technical debt thing is an artifact of a legacy approach to software development. Embracing fail forward, feature flagging and continuous delivery typically solves the fundamental issues in software, and for people who need their fix of best practices uber alles, there's open source projects.

  • Richard Lake (google) in reply to DocMonster

    The really sad thing is when IT management doesn't even care about tech debt. Our team is told constantly how we need to focus on business needs, and if a project doesn't have observable business benefit, it is canned.

  • Richard Lake (google) in reply to Raj

    There's a great article on this site that talks about, in my opinion, one of the biggest causes of technical debt, at least in Enterprise level companies:

    http://thedailywtf.com/articles/the-billable-hour

  • Anonymous (unregistered) in reply to DocMonster

    Well, "making sure their code can be modified and fixed" is a very loose thing. I agree there is the basic level (stuff that ends up on this site, actual dead code and logic that is provably redundant) which should be eliminated on sight, but beyond that it gets much less clear.

    Rewriting even a small function is a risk, plus there is a tendency that the definition of "clean code" shifts over time or with different maintainers, possibly resulting in the same bit of code being rewritten multiple times. This can accelerate to a pace where you never actually profit from the improvement. E.g. the first guy thinks everything must be configurable, but it is actually never used, then the next one simplifies it away again…

    Balancing "no refactoring" and "refactoring all the time" is a delicate thing, and it does require awareness in the team or a technically versed manager (preferably both).

  • robby the robot (unregistered)

    Face reality.

    We either ship ugly code that just about works and the customer pays, or we wait till it's perfect and discover the customer has bought a different product.

  • Object delete. (unregistered)

    Decent code, on-time delivery, within budget. Choose two. If you choose all three, you won't get the first one, because that is what isn't easy to measure.

  • (nodebb) in reply to robby the robot

    Ezzackly . We are all beta-testers, and paying $BIG_COMPANY for the privilege.

  • (nodebb) in reply to DocMonster

    Tech debt is not really visible to anybody except devs. The PHBs/PMs/etc., may wonder why it takes so long to add a feature and/or why there are so many bugs, but when told that it is at least partially due to tech debt, it is just ignored. For years nobody believe me when I complained about how poor our codebase was until new devs came onboard and started complaining too.

  • (nodebb) in reply to P

    I mentioned "Mythical Man Month" to a PM (who used to be a dev) - he had never heard of it.

  • Wtf (unregistered)

    Why does everybody gloss over the fact that Karl is grossly incompetent?

  • LaughingItOff (unregistered) in reply to Ryan of Tinellb

    This can be done by chunkating in strings of 0-padded 4 characters and then attempting to turn each string into a character using System.Convert.ToChar(System.Convert.ToUInt32("0x" + myStringToTest + "", 16)).ToString().

    If any of these conversions returns an exception, then it's not hexadecimal.

  • LaughingItOff (unregistered) in reply to Object delete.

    But he reinvented a functions which comes with the basic libraries. That's the LOL.

  • (nodebb)

    If you don't use Integer.TryParse, I think a Python for-else loop would improve this function's inner loop.

    for j in range(10): ...if valid: break else: return False

  • gumpy_gus (unregistered)

    Not quite enterprisey enough. Not enough constants stored in SQL tables or XML embedded in SQL Tables, with a JSON chaser.

  • gumpy_gus (unregistered) in reply to gumpy_gus

    And I forgot--- it's not a Java EE bean !!

  • LaughingItOff (unregistered) in reply to gumpy_gus

    I've seen HTML returned by SQL. Not by the sprocs returning the data. The insert sprocs. Meaning in the tables. And of course it was all pre-2.0, old school postback classic ASP on the front end.

    I can't tell you how much of a Mac Gyver project this was.

  • Barf4Eva (unregistered) in reply to Wtf

    Who knows, maybe he was just starting out his career? The important thing is that he realized the horrific mistake and the error of his ways, manned up to it, and wanted to make the correction. What kept him from following through on what he wanted to do was company policy and release protocols.

    But... at the SAME time.. you'd think someone would realize in C# that, you know, someone has already invented the wheels. :) And a quick MSDN online and stackoverflow googling w/ the right questioning would get you to the answer.

    But then again, just starting off one's career in C# land... or maybe someone who is very much a greybeard and hasn't stepped outside their comfort zone for quite some time... and with a tight "crunch" involved... well, shit happens. :D

    Then again, if I saw someone on my team doing this, I'd be shooting laser beams from my eyeballs....

  • ZZartin (unregistered)

    Integer.TryParse will return true on some things this function won't. Don't know if that intended or not, if it is then this isn't horrible other than using a nest loop.

  • (nodebb) in reply to DocMonster

    There are reasons to rewrite library functions. For type conversions, specifically, you might want to handle NULL as triggering a default instead of silently being coerced to zero or return a result without that awful out syntax. I like out for more complex functions but it's ridiculous for something as stupid as type conversion where you just need the result inline. Everybody sees the cost of "dur hur don't reinvent the wheel" but misses the savings of having a base library that functions exactly how you need it to.

    I agree that cluelessness about technical debt is an outrage though. I just left a place that was cutting corners everywhere to make up for additional spending required because they wouldn't make the H1Bs follow any rules or fix any mistakes. It's funny that Mythical Man Month was mentioned too because piling on more unqualified bodies (in development, where mistakes are made, not operations, where they're coped with) is part of that increased expenditure. You can't tell these people anything because they think they know everything despite a mountain of evidence to the contrary.

  • Decius (unregistered)

    Why would int32.tryparse be appropriate? How would you tell the difference between "NaN" and "0" as inputs?

  • Googolplex (unregistered)

    I'm pretty sure this function is ContainsOnlyNumericDigits(), because you could pass it a billion-character-long string of all zero characters and it would return true. So it comes down to knowing what requirements were being met. ...Of course, it sure seems likely that Int32.TryParse() would have fit the bill.

  • Erin (unregistered) in reply to DocMonster

    PHBs not understanding tech debt is a problem that will never be solved, at least not in general. When trying to sell version N+1 to a customer, "now does ShinyNewThing!" is a potential selling point, even if the customer will never use it. "Cleaned up the (closed) source code" is not. Similarly, "fixed bugs" is a selling point, but "fixed bugs 10% faster thanks to that code cleanup" is not.

    And really, much as I hate to say it there's some merit to that. 90% of messy code works. Sure its fun to read TDWTF stories of the 10% that doesn't, and definitely frustrating when you're the one who has to fix a critical bug in that 10% at 2am.. but unless your company has much bigger development issues than just tech debt, it /mostly/ ends up being fine. And cleaning up tech debt can take a lot of developer time, and be risky in its own right as there's no guarantee that your new clean code won't introduce new bugs and edge cases that the old messy code was correctly handling.

    All that put together means that not only is cleaning up tech debt a pure cost center, its also a risk center. That's a hard sell to managers and beancounters who spend their days focusing on how the product is used more than how its created.

  • (nodebb) in reply to DocMonster

    The trouble is in how code is “modified and fixed”. Someone calls out some way that the sofware doesn't do what it should. So a programmer traces along the logic to see where its behaviour deviates. At that point, they do changes that are as localized as possible and fit in the new behaviour. Then the code does what it should, and so the work stops there.

    At no point in the whole process has anyone tried to understand the big context or the structure as a whole. So at no point has anyone tried to make the big context easy to comprehend - having consistent and sensible structures and substructures, or exposing at each level of detail no more than the average programmer can keep in mind at the same time, or seeing to it that each entity has a name that still exactly fits its purpose and content and so on. That's what the original software architect has done when you're lucky; it's been put completely out of focus immediately after they had finished.

    And that's how those endless daisy chain of ifs with completely disparate concerns come to life, or structures with a nesting depth of seven and more, or methods that fit their purpose with one set of parameters but do something completely different when just one of the parameters is changed, and so on.

    Now nobody has enough brain capacity to ever have the chance of understanding any context large or small with all its ramifications in an orderly manner. So all the programmers that follow are simply forced to add mess to the mess by tracing some program flow that demonstrates the problem at hand and adding local changes.

    There's no remedy in sight, because cleaning up the mess would mean at least blowing half a year into refactoring just a smithering of the code, and rewriting the code would mean forgetting a ton of ramifications that have been patched in at the time.

    Neither is commercially viable in any way any longer. And that's the reason that the business driven big hats tell the programmer to just slog on and waste no time on old code.

Leave a comment on “Is Num? I'm Numb”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article