• (cs) in reply to Joe
    Joe:
    I'd like to know your definition of a bug. Because depending on the company, the threshold can change quite a bit.
    "It's not a bug, it's a feature!"
  • Edward Royce (unregistered) in reply to astrotrf
    astrotrf:
    My last project: 35,000 lines of C code

    Oh yeah!?

    A project I did 15 years ago was 25mb of COBOL source code!

    Which, since it's COBOL, probably was about 500 lines.

    What the hey. I figured I'd put my foot forward before everyone else started in.

  • BlueDeath (unregistered) in reply to Biff

    Testing isn't necessary. My code is flawless. Though sometimes it did display some bugs, but those were exceptions, not common. If there is spare time for testing, I would rather spend that time prefecting my code.

  • biggles (unregistered) in reply to Waffle

    F**k it, we'll do it live!!

  • The Fake WTF (unregistered) in reply to matt
    My dog is awesome.

    I ask my dog what the derivative of y = (5ln(4x) + y root(10) - 5 * 10010^(5x)) * (9 - (33)) is, and he says nothing.

    Beat that.

    Derivative with respect to which variable?

  • James Drissel (unregistered)

    I think that organizations like this are ripe for takeovers. Think about it, bring in some smart new money, fire the idiots in middle management that caused this appalling situation (this happens in takeovers anyway, but that they actually deserve it is a plus).

    If I was a customer or a stockholder, I would be after that CEO for failing to take due care in the operation of the business. Under SOX, he could be exposed to civil and criminal penalties for allowing this. It is like it would have been if the CEO of Exxon had known that Hazelwood drove the Valdez drunk on a regular basis – before he destroyed half the Alaska coastline.

    This kind of failure to exercise due care should be reported to the regulatory agency that regulates the industry, in this case the SEC. I think that they would take a very dim view of this kind unprofessional behavior anywhere near that “fiduciary responsibility”.

    Attention managers, the days of running a business like a pirate ship are over. Keep it up and it will be you that get Keel-Hauled… http://en.wikipedia.org/wiki/Keelhauling

    Walking the plank would just be too merciful.

  • Dave G. (unregistered) in reply to astrotrf
    astrotrf:
    My last project: 35,000 lines of C code

    Design, development, debug time: 4 months (while doing other things)

    Total bugs in beta test: 2

    Total bugs in production use at over 60 clients after 2 years: 1

    You are not impressive, and nobody cares what you have to say. Shutup.

  • Captain Obvious (unregistered) in reply to Biff
    Biff:
    Use your brains, people! Don't call it done if it isn't done! Think about *all* the code paths! Learn the system you're working with.
    Well, I imagine that works if you're writing 50 line Basic utilites. Unfortunately in the real world life isn't so simple.

    Presumably you're also one of those people who doesn't believe testing is necessary as your code is invariably flawless...

    I agree with not calling it done unless it's done. "It's done, but we haven't tested it yet" really means "it's not done." Knowing that management will want to deploy as soon as "it's done", we need to be sure not to declare it as such until we've tested it and can stand behind it.

  • Captain Obvious (unregistered) in reply to BlueDeath
    BlueDeath:
    Testing isn't necessary. My code is flawless. Though sometimes it did display some bugs, but those were exceptions, not common. If there is spare time for testing, I would rather spend that time prefecting my code.

    You might spend more time prefecting your spelling instead.

  • (cs) in reply to A. Developer
    A. Developer:
    If you get into a situation where the boss is demanding untested functionality in production, then push back. Write a brief but direct e-mail, like follows:

    Mr. Boss:

    I understand the timeline for feature X is crashed and that feature X is on the critical path for our current project.

    Feature X has not gone through our standard procedures for review, testing, or deployment. Defects may exist in feature X that have not been discovered and therefore cannot be removed. Without standard procedures, these undiscovered defects may evidence themselves in production. This may impact our systems, possibly in catastrophic ways.

    Are you absolutely sure you want to deploy feature X to production without putting it through the standard procedures?

    A. Developer

    If you get back a "Yes", then kick your feet up. The responsibility lies entirely with the boss.

    Okay, good.

    Sitation 1: if you have statndard procedures then most likely you have management backing those procedures. So these e-mails only need to get written in real emergencies. In that case you problably get an affirmative reply. Case closed.

    Situation 2: There are no procedures. Your manager is a weasel/jerk/MBA. He gave you the directive to code and deploy verbally and does not confirm your e-mail (maybe even deletes it - although this should not possible because of Sarbanes-Oxley). What do you do then ? Are you going to put your ass on the line and go ahead anyway ? Or are you are going to refuse and risk a career-limiting dismissal ?

    Imagine this: Your deployment goes horribly wrong (like in the OP). You end in front of a panel of manager (each in full-tilt CYOA mode) in a meeting room somewhere. The dialogue before you come in is as follows:

    CEO to CIO: "I want the head of the person who is responsible. You are in charge of IT. It is your department's fault." CIO to CEO: "It is the fault of the CTO. His production environment failed"

    CIO to CTO: ..... CTO to CIO: .....

    < repeated ad nauseam until the fingerpointing is with our unfortunate developer again >.

    Development manager to developer: "You deployed a change in the production environment without testing and my knowledge. We will have to let you go." Developer: "I have here printouts of the e-mail sent to you confirming your verbal directive to implement and deploy feature XYZ in production without testing and you affirmative reply to it. Let me go and I will sue to the ass off the company for unfair dismissal. I have furthermore printouts of earlier e-mail which show that changes are routinely deployed in production without testing by directives on numerous previous occasions."

    So what does the developer do if he doesn't get an affirmative e-mail ? And to make things worse the manager may be a lying weasel ..... I leave that up to you to imagine ...

    For me personally, I would refuse to implement and deploy without written (e-mail) confirmation right away. If an issue is being made out of this then you just have to show backbone.

  • (cs) in reply to Joe
    Joe:
    Nicholas:
    You know, the real problem in this scenario is with the lousy developers. They should just frickin' get it right the first time. I don't know how many hundreds of people I've met who really just can't be trusted to code. Use your brains, people! Don't call it done if it isn't done! Think about *all* the code paths! Learn the system you're working with. And don't whine about not having the time. Just remember this mantra, which has always served me well: no matter how much you think it's somebody else's fault, it's really your fault. And your problem. You have no idea the world of problems this attitude will fix, and how far it will take you. Though it may just make you frustrated with everybody else's incompetence.

    I'm guessing the most complex application this guy's ever worked on was "Hello World!".

    ... and it came out as "Helo World!".

  • (cs) in reply to akatherder
    akatherder:
    A. Developer:
    If you get into a situation where the boss is demanding untested functionality in production, then push back. Write a brief but direct e-mail, like follows:

    Mr. Boss:

    I understand the timeline for feature X is crashed and that feature X is on the critical path for our current project.

    Feature X has not gone through our standard procedures for review, testing, or deployment. Defects may exist in feature X that have not been discovered and therefore cannot be removed. Without standard procedures, these undiscovered defects may evidence themselves in production. This may impact our systems, possibly in catastrophic ways.

    Are you absolutely sure you want to deploy feature X to production without putting it through the standard procedures?

    A. Developer

    If you get back a "Yes", then kick your feet up. The responsibility lies entirely with the boss.

    Dear A. Developer,

    Well then get with the testers and make sure this works before we put it out there. What's so difficult about this?

    Sincerely, Your Boss

    Congratulations! You have just retaken responsibility as far as PHB is concerned and you get to work extra hours.

    Dear Mr. Boss,

    As per your directive I am coordinating with the QA testers. The additional work required for testing will push back the deployment as follows and the original targeted deployment will not be met:

    < ... yadayada - Schedule - yadayada .. >

    Based on your previous directive QA and myself will conduct the work as per the revised schedule detailed above resulting in a deployment delay of x working days.

    Best Regards, A. Developer

  • Founder (unregistered) in reply to Reverend
    Reverend:
    powerlord:
    It could be worse... it could be Schrödinger's cat!

    The cat is immortal as long as you never look at it.

    10 years ago, I put my cat in a box to see if it could be alive and dead at the same time. After a while, it started to smell, but theoretically is still both alive and dead.

  • Metal Lord (unregistered)

    The only language I know that can make a sailor cry is COBOL

  • Damon (unregistered) in reply to JC

    I still (just) do work at LB and none of the stuff I work on or have ever worked on over the last 13+ years on the fixed-income/derivatives side has ever been handled this way. Build quality and testing are generally good. OTOH I don't generally work on the flow side of the business where pressures are higher and some would claim that IQs are lower.

    Rgds

    Damon

  • (cs)

    I've written these systems and there is always the potential brown-pants moment right after deploying a change - no matter how much testing has been done. You should always have a means of sending cancel orders for everything you have on the market though. That way you limit your exposure somewhat.

    Daniil looked up orders caught by the web service but not processed

    A web service?! The systems I wrote for order processing needed sub millisecond latency. Parts of the system were co-located because even if they were travelling at the speed of light the orders couldn't get around the globe fast enough and they're using a web service?

    As for pay, at least where I live, the right financial company will pay absolute top dollar for good developers. The only companies paying more are the online poker companies, which shows how much money they make!

  • (cs) in reply to Outlaw Programmer
    Outlaw Programmer:
    JC:
    John:
    And - most places I've worked at have done this, at least to some extent.

    Financial institutions really ought to know better though

    Financial institutions seem to be the worst for this sort of stuff in my experience. I used to work at Lehman Brothers and we had several similar instances caused by lack of testing and a general, we need it in there ASAP attitude.
    The This mirrors my (limited) Wall St. experience, too. Everyone in management hated the idea of testing. Most clients just could not grasp the concept of testing. Yes, you're buying extra hardware for the QA layer but you will save thousands (millions?) in the long run, dammit! Clients that actually did buy servers for QA would often neglect them so that they became wildly out of sync with their production systems.

    Eventually, the company motto became, "We'll test it in production!"

    The problem with testing is still the same: it takes ±2 times longer than to develop. So if dev takes one day, testing takes two and the whole including deployment takes ±1 week. For business this is far too long. They need the changes by yesterday. Markets react quickly, sometimes within hours sometimes even less. Financial institutions have a bit the habit of losing money (think only of cash burn). So, all right, they loose some bucks on day X because something didn't work well, but then they earn bucks, say 10 times more often, because the stuff was implemented in time and it actually worked. Thus, of course, this is stressing, but not killing. Logically, the business people must play the angry role to make sure problems don't happen all the time, but when they happen once in a while it doesn't hurt as much as to be always the last one who implements important changes that allow to make the big bucks.

  • Bitter Like Quinine (unregistered)

    Long, long ago in a job far, far away...

    (Scene: the 'workshop' of a small SCADA development team)

    Boss: I've fixed that problem where the screen updated twice.

    Me: Uh, the low priority one we said we'd fix during the plant's next scheduled shutdown?

    Boss: Yes, but some of the users complained. I've got the package ready to go out onto the machines.

    Me: sigh Okay, I'll test it on a dev box over lunch and we can roll it out this evening when there's less people around.

    Boss: I've already tested it! It can go out right now. starts typing

    Me: Well, I'd kinda expected you'd test the fix before packaging. I'm talking about testing the install procedure for sanity, missing files, that sort of...

    Boss: Why are the main boxes down?

    Me: They're not, I'm logged on to TSR n...oh!

    Of course, the install had a bug in it. One that effectively delisted the mass-storage control subsystem, i.e. instantly took all the drives off-line, including paged memory. Funny thing, but if you disable the low-level HDD driver from a system, it won't boot again either. I spent the rest of the day wandering from machine to machine with a clone of one of the dev drives so that I could boot each box off it, repair the damage and restart normally.

    Of course, the Boss wouldn't believe it was anything to do with him; the bug in his package was obviously a result of the crash. Though I noticed he did delete the (uncrashed) copy from his work area, so no-one could say otherwise.

  • FinnGamble (unregistered) in reply to Biff
    Biff:
    Well, I imagine that works if you're writing 50 line Basic utilites. Unfortunately in the real world life isn't so simple.

    Presumably you're also one of those people who doesn't believe testing is necessary as your code is invariably flawless...

    Actually, it is possible to create flawless code. And this comes from someone working with huge ERP software. Divide the code into small enough pieces and testing each bit gets easy. You can also do things such as simulating logic and file formats with paper and pencil. Obviously, it gets harder and harder the more people there are working at the same project, but it still can be done.

    It's the biggest wtf in the industry that so many people have the "there are always bugs in software" attitude. It's so deep in their minds that that they actually allow them to happen! However, there is nothing magical about software that requires them to always be buggy.

    Another problem I guess is that it slows down the development. Almost no management will tolerate such slow programming. Unless you do "X" lines of code a day, they'll think you are lazy, not careful. In a lot of cases they also don't mind selling a broken product because then it allows them to sell the upgrade, too, which fixes some of the old bugs and introduces a whole bunch of new ones.

  • (cs) in reply to Founder
    Founder:
    Reverend:
    powerlord:
    It could be worse... it could be Schrödinger's cat!

    The cat is immortal as long as you never look at it.

    10 years ago, I put my cat in a box to see if it could be alive and dead at the same time. After a while, it started to smell, but theoretically is still both alive and dead.

    I think even Schrödinger would agree that putting a cat in a closed box for 10 years will quite certainly kill it. (Unless you made a feeding hatch or something.)

    And if it starts smelling, I sure hope for you the smell isn't almond-like...

  • TC (unregistered)

    In the modern capitalist 'make a profit whatever the cost' environment none of this is surprising. Here is how my experience of software projects go...

    1. Business asks for software solution to problem.
    2. Business manager with next to no knowledge of problem allocates arbitrary funds to project.
    3. Allocated funds cannot provide effective quality assurance for software solution.
    4. Project Manager enforces unreasonable deadline and insists on reporting to appease higher ups.
    5. Software Developers advice that funds and time are less than ideal are met with typical excuses designed to absolve responsibility.
    6. Software Developer presses on doing the best they can under the circumstances.
    7. Software solution delivered with problematic bugs and little or no quality assurance.
    8. Project Manager celebrates (and gets patted on the back) for delivering said software solution 'on time and within budget'.
    9. Productionisation of software solution results in bugs that cause business process failure.
    10. Software Developer blamed for not producing quality software.

    And so the cycle continues...

  • Proko (unregistered) in reply to Nicholas
    Nicholas:
    Think about *all* the code paths!

    Emmm... what software do you write? "all the code paths"? You know that this is basically impossible in real life. Like mentioned above, it works only with really really small programs or maybe in little larger programs what are extremely important( used for example in space shuttles, where little mistake might cost lives ) and where cost for intensive code tracing and testing is affordable. That is why it only works in places like NASA, ESA, maybe CIA and NSA, where purpose is not profit. In 99.9% of places it will never going to happen, because it simply cost's to much and client don't understand why the cost is that high and choose a product what was created cheaply. And nobody want's to lose clients :)

  • (cs) in reply to Rob
    Rob:
    For the love of God, I seriously hope you're being sarcastic.

    Yeah, I'm sure at least one of the 25 or so people who posted before you was being sarcastic.

    You might try using the "Quote" button so people will know who you're replying to - your comment doesn't make any sense without context.

  • (cs) in reply to Dave G.
    Dave G.:
    astrotrf:
    My last project: 35,000 lines of C code

    Design, development, debug time: 4 months (while doing other things)

    Total bugs in beta test: 2

    Total bugs in production use at over 60 clients after 2 years: 1

    You are not impressive, and nobody cares what you have to say. Shutup.

    Well, I didn't post that information to be impressive, just to refute those who think that only trivial software can be essentially bug-free; otherwise, I wouldn't have bothered. There'll always be those who won't believe it or don't want to believe it, and I've no interest in debating with them. I was just backing up the guy who was getting disparaged for blaming developers for bad code.

    I am, however, fascinated by your attitude that someone who is demonstrably good at writing code is not worth listening to.

    BTW, for the OP who asked: my definition of a bug is anything that fails to be as intended, no matter how trivial. In fact, one of the two beta-test bugs I cited was a bug in a bit of diagnostic code that was not technically part of the production system (it failed to correctly calculate memory use).

    It's the biggest wtf in the industry that so many people have the "there are always bugs in software" attitude. It's so deep in their minds that that they actually allow them to happen! However, there is nothing magical about software that requires them to always be buggy.

    This is the absolute truth.

    Of course, there are always bugs in most software, not because it's inevitable, but because there are so many people taking money for writing software when they're no bloody good at it. This very web site offers an abundance of examples of that.

    Partly, this is because there is far more software to write than there are good programmers to write it. Partly, it's because software development managers often haven't a clue which of their programmers are really good and which aren't. Partly, it's because vendors, trying to respond to the demand for ways to get poor programmers to produce better code, invent ever more complex software development environments instead of simpler ones that are easy for poor programmers to master.

  • (cs)

    Actually, that's just a sound business practice. Paying 10k for a program that has a 1 in 10 chance of making you lose 1000k is still cheaper in the long run than paying 200k for a program that is perfect.

    "I don't like it any more than you"

  • Edward Royce (unregistered) in reply to Metal Lord
    Metal Lord:
    The only language I know that can make a sailor cry is COBOL

    Nope. Add in RPG and you've got a winning combo.

    You know I wonder if some sad, crazy son of a gun out there in the world went and turned RPG into some sort of web scripting language.

    Oh for the love of God!

  • John D (unregistered) in reply to The Fake WTF
    The Fake WTF:
    My dog is awesome.

    I ask my dog what the derivative of y = (5ln(4x) + y root(10) - 5 * 10010^(5x)) * (9 - (33)) is, and he says nothing.

    Beat that.

    Derivative with respect to which variable?

    Doesn't matter what variable the derivative is in respect to because y = 0.

  • Edward Royce (unregistered)

    Hmmmm.

    Just curious. What language are financial systems written in? I'd expect C/C++ but I've read job listings that include Java.

    No desire to deal with that kind of stress but, as an investor, my interest has been perked.

  • (cs) in reply to Nicholas
    Nicholas:
    Think about *all* the code paths!
    Isn't that what some people like to call the General Halting Problem?
  • Kuba (unregistered) in reply to Walleye
    Walleye:
    My dog is working on a Unified Field Theory. He's out in the backyard digging holes. I think he's building a supercollider.

    Truly brilliant (not brillant). You've got me crying. What a great mid-day stress reliever. Had to print it out and post it above my desk. Thank you!!

  • (cs) in reply to Edward Royce
    Edward Royce:
    Hmmmm.

    Just curious. What language are financial systems written in? I'd expect C/C++ but I've read job listings that include Java.

    No desire to deal with that kind of stress but, as an investor, my interest has been perked.

    Not sure what you'd qualify as "financial systems," but the vast majority have a back-bone in Cobol that is, sadly, never going to go away. The more adventurous shops in this area venture into Java, because they have this half-assed idea that they can train ex-Cobol programmers up (usually into J2EE and disaster).

    For performance-critical systems, they use C. They do not use C++ (for reasons I can only guess at). Indeed, a certain Scandinavian company mentioned above will not even let their programmers use C99 ... because that would be unportable, of course. Never mind that all their core hardware is Sun.

    In short, they spend so much time dealaing with CYA that they almost never make sensible technology choices.

    If you're an investor, I'd suggest that soybean futures are a better way to go.

  • Kuba (unregistered) in reply to Edward Royce
    Edward Royce:
    Hmmmm.

    Just curious. What language are financial systems written in? I'd expect C/C++ but I've read job listings that include Java.

    No desire to deal with that kind of stress but, as an investor, my interest has been perked.

    Jane Street Capital, a private investment firm (no clients, they work for themselves) uses OCaml and they like it. They got a bunch of fairly bright people there, and from what I gather their practices must be quite non-WTFy.

    The only thing they haven't quite got is how to use C++ properly, since a lot of reasons they've cited for OCaml being better than C++ is simply due to the fact that they haven't read any Scott Meyers. Heck, I was really not amused by their supposed reasons for C++ being bad. Yet, even if for mostly wrong reasons, I think that their choice of OCaml (over C++) was good.

    I have no connections with them, only read some of their posts on OCaml lists.

  • Franz Kafka (unregistered) in reply to SQB
    SQB:
    Actually, that's just a sound business practice. Paying 10k for a program that has a 1 in 10 chance of making you lose 1000k is still cheaper in the long run than paying 200k for a program that is perfect.

    "I don't like it any more than you"

    How about paying $50k for something that has a 2% chance of a $1m loss?

  • Thunder (unregistered) in reply to snoofle
    snoofle:
    I've worked for Wall Street brokerages for nearly 20 years now, and it's ALWAYS code/cursory test/deploy. Screw QA and their time-wasting procedures. Screw the deployment team (we don't care about keeping DR versions of software up to date, we're working in PROD).

    However, I've found that the pay, if you're a US citizen, has been quite good - more than double what I'd make in a comparable non Wall Street position.

    One thing I've learned; if your boss is one of these we-don't-need-to-test jerks, just blindly obey and let it hit the fan. The next time around, they usually soften their stance a bit. If not, let it hit the fan even bigger. As long as you CYA with memos detailing the risk, you are blameless, and come across after-the-fact as having tried to remedy the problem. In the short run you lose; in the long run you win.

    And customers? Faugh, who cares about them... as long as your ass is covered.
  • Ilya Ehrenburg (unregistered) in reply to Captain Obvious
    Captain Obvious:
    BlueDeath:
    Testing isn't necessary. My code is flawless. Though sometimes it did display some bugs, but those were exceptions, not common. If there is spare time for testing, I would rather spend that time prefecting my code.

    You might spend more time prefecting your spelling instead.

    Methinks you might spend more time prefecting your sarcasm detector.

  • Argent (unregistered) in reply to Archibald Buttocks

    This is why I got out of safety critical systems.

    Though you get less "deploy, deploy, deploy" pressure, the stress level when you're trying to find a bug that nearly led to a train being derailed is still more than I was willing to deal with.

  • Argent (unregistered) in reply to Thunder
    Thunder:
    And customers? Faugh, who cares about them... as long as your ass is covered.
    Short term, they're screwed whether you fight or not. Long term, people start listening to your memos.
  • aliquam (unregistered) in reply to Won't Get Fooled Again
    Won't Get Fooled Again:
    "After running some numbers, Daniil discovered that the amount of lost commissions, sales, and trades outweighed the cost of testing and fixing the change over ten-fold. ... "

    Yeah, right.

    All these fake Daily WTF stories always have a "tell" the makes it obvious it was either made up wholesale or embellished beyond all recognition.

    The fake is a lie.

  • (cs) in reply to Kuba
    Kuba:
    Edward Royce:
    Hmmmm.

    Just curious. What language are financial systems written in? I'd expect C/C++ but I've read job listings that include Java.

    No desire to deal with that kind of stress but, as an investor, my interest has been perked.

    Jane Street Capital, a private investment firm (no clients, they work for themselves) uses OCaml and they like it. They got a bunch of fairly bright people there, and from what I gather their practices must be quite non-WTFy.

    The only thing they haven't quite got is how to use C++ properly, since a lot of reasons they've cited for OCaml being better than C++ is simply due to the fact that they haven't read any Scott Meyers. Heck, I was really not amused by their supposed reasons for C++ being bad. Yet, even if for mostly wrong reasons, I think that their choice of OCaml (over C++) was good.

    I have no connections with them, only read some of their posts on OCaml lists.

    O Jesus.

    Does it matter?

    Who to?

  • (cs) in reply to SQB
    SQB:
    Actually, that's just a sound business practice. Paying 10k for a program that has a 1 in 10 chance of making you lose 1000k is still cheaper in the long run than paying 200k for a program that is perfect.

    "I don't like it any more than you"

    Paying 9.999999 (I just threw that in there for the six sigma boys)K recurring is still cheaper than paying 10K.

    In fact, paying $1 for something that stands no chance whatsoever of "making you lose" 1000k is also quite good value.

    I don't know about you -- I'm just a simple country boy -- but if I were to be given the option of paying $200,000 for a program that is guaranteed not to lose me any money whatsoever (other than, perhaps, the $200,000 I'd sunk into it), or paying $10,000 for a program that will, on a one in ten basis, lose me $1,000,000, then I'm going to opt for the former.

    Of course, I'm not the Federal Government.

  • (cs) in reply to FinnGamble
    FinnGamble:
    Biff:
    Well, I imagine that works if you're writing 50 line Basic utilites. Unfortunately in the real world life isn't so simple.

    Presumably you're also one of those people who doesn't believe testing is necessary as your code is invariably flawless...

    Actually, it is possible to create flawless code. And this comes from someone working with huge ERP software. Divide the code into small enough pieces and testing each bit gets easy. You can also do things such as simulating logic and file formats with paper and pencil. Obviously, it gets harder and harder the more people there are working at the same project, but it still can be done.

    It's the biggest wtf in the industry that so many people have the "there are always bugs in software" attitude. It's so deep in their minds that that they actually allow them to happen! However, there is nothing magical about software that requires them to always be buggy.

    Another problem I guess is that it slows down the development. Almost no management will tolerate such slow programming. Unless you do "X" lines of code a day, they'll think you are lazy, not careful. In a lot of cases they also don't mind selling a broken product because then it allows them to sell the upgrade, too, which fixes some of the old bugs and introduces a whole bunch of new ones.

    Good lord, what an idiot.
  • (cs) in reply to Edward Royce
    Edward Royce:
    Just curious. What language are financial systems written in? I'd expect C/C++ but I've read job listings that include Java.

    I use C/C++ for the backend processing systems. Java is used for less performance critical areas, and VB/C# used for frontend desktop applications. You can also throw some mainframe stuff in there, but I reckon you're not interested in that.

  • Edward Royce (unregistered) in reply to mxsscott
    mxsscott:
    Edward Royce:
    Just curious. What language are financial systems written in? I'd expect C/C++ but I've read job listings that include Java.

    I use C/C++ for the backend processing systems. Java is used for less performance critical areas, and VB/C# used for frontend desktop applications. You can also throw some mainframe stuff in there, but I reckon you're not interested in that.

    I haven't done anything with mainframe or even mid-range in a pretty long time so it wouldn't even matter. I was just curious because the advertisements seemed to contain every variation and permutation of technology imaginable.

    In a performance oriented situation like that I always thought the demands of the industry would result in a "best practices" that would eliminate everything but the most useful, for that implementation, technology.

    Thanks for rounding everything out.

  • James R. Twine (unregistered) in reply to astrotrf
    astrotrf:
    My last project: 35,000 lines of C code

    Design, development, debug time: 4 months (while doing other things)

    Total bugs in beta test: 2

    Total bugs in production use at over 60 clients after 2 years: 1

    While that may be quite a feat in some circles, this entirely depends on what that software is doing. I can write 30K lines of C code for a simple logical process like text extraction (or file format identification).

    This is a relatively simple process when compared to things like, for example, algorithmic execution of market orders, tax lot accounting, plesiochronous (kinda) sync. of EMS/OMS system with regard to Tickets, Orders, Executions, etc.

    A system with only 8K lines of C can be many times more impressive than some other 30K line system - the number of lines have less to do with the complexity than the code itself.

    Not to say what you have done is or is not impressive, or what you have to say is relevant. Personally, I believe that ALL bugs are preventable. Given enough time, and talent, of course.

    James.

  • (cs) in reply to Joe
    Joe:

    I'd like to know your definition of a bug. Because depending on the company, the threshold can change quite a bit.

    So are you seriously implying (like many others seem to do) that there is absolutely no way possible in this universe for a developer to actually design and develop an application properly with few or no bugs, at all?

    In my experience, this defeatist attitude is mostly propagated by incompetent developers who either start coding without a proper design, or fail to consider various code paths or error conditions; and so assume that everybody is the same. Therefore, all development is bound to failure from the start.

    I do not consider myself perfect in any way, nor I think I am such a hot-shot super developer, but I take pride in the fact that I have enough skill, talent, knowledge and experience that I can recognize potential pitfalls and failure conditions and maybe even a proper solution, with a bit more than a cursory consideration of the problem.

     -dZ.
  • FinnGamble (unregistered) in reply to real_aardvark
    real_aardvark:
    Good lord, what an idiot.

    What makes you say so? English isn't my first language so maybe my delivery isn't good. But yeah, a statement like that makes you seem like a fucking genius in my eyes. Congrats. I've been programming for 25 years, so I guess not everyone feels I am an idiot.

    In fact, maybe you can give me the basic math which tells all large software need to have bugs?

    As I said, I've worked with a big team on a family of ERP software which is used by big logistics and manufacturing companies, and I am yet to see a module which couldn't have been divided into small pieces to be tested independently.

    Obviously, we are interfacing with SQL Server and Crystal Reports and all that stuff, which leaves a lot out of our control. But still, I say it's possible to create software, no matter what size, which doesn't have a single programming error. I'm not saying it's easy or cheap. But I strongly feel that bugs are not something that should be automatically accepted, even though it seems to be the norm.

  • Ilya Ehrenburg (unregistered) in reply to FinnGamble
    FinnGamble:
    But still, I say it's possible to create software, no matter what size, which doesn't have a single programming error. I'm not saying it's easy or cheap. But I strongly feel that bugs are not something that should be automatically accepted, even though it seems to be the norm.
    When was the last time you read a book without any typos? And that's easy, compared to software. For a sufficiently complicated piece of SW, there are just too many possible code paths to check all possibilities.
    and I am yet to see a module which couldn't have been divided into small pieces to be tested independently.
    But you also have to check whether these small pieces have been assembled correctly, introducing many more possibilities to overlook something. While I don't deny that it's possible to create large software without a single programming error, I believe that if you do that in reasonable time, you've been lucky. To be sure that your software is bug-free takes very long. Software with very few bugs, that's a different matter.
  • Noob (unregistered) in reply to Ron Larson
    Ron Larson:
    But not planning for failure was a bigger mistake.

    Worse than failure?

  • AndyC (unregistered) in reply to FinnGamble
    FinnGamble:
    In fact, maybe you can give me the basic math which tells all large software need to have bugs?

    The Halting Problem

  • My Name (unregistered) in reply to AndyC
    AndyC:
    FinnGamble:
    In fact, maybe you can give me the basic math which tells all large software need to have bugs?

    The Halting Problem

    It would be wonderful if all the CS students would stop misinterpreting the Halting Problem to say a piece of software cannot be bug-free. In the first couple lines of the linked article...

    "In computability theory, the halting problem is a decision problem which can be stated as follows:

    Given a description of a program and a finite input, decide whether the program finishes running or will run forever, given that input.

    Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist."

    A basic understanding of English would preclude people from taking that to mean that it is not possible to have bug free software.

    What Turing's proof means:

    • You cannot develop an algorithm that will tell you whether an arbitrary function will halt given an arbitrary finite input.

    What Turing's proof does not mean:

    • It is impossible to determine whether a program will halt given a(ny) finite input.

    While it is true that a general purpose algorithm to solve the halting problem for all possible program/input pairs has been shown to be impossible/nonexistent, that does not mean you cannot tailor one to your specific problem domain (cf. your own link, although you will have to read more than the first couple lines). Using the Halting Problem to excuse lazy code is ignorant at best.

Leave a comment on “Deploy! Deploy! Deploy!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article