Crackers are a myth



  •  Today I bring you yet another WTF from our latest hire. We shall be refering to him as Paul because he reminds me so much of a certain female individual that has achieved legendary status on this site.

    Paul was tasked with moving a certain web application from our internal server which is only accessible localy to our internet server that is accessible from the web. The application was a typical LAMP job consisting of barely three pages of forms whose sole purpose in life is to log certain tasks the team performs. It was initial built to run on the internal website and such never made very secure or robust. A WTF in itself you might say but it has served its purpose well within our small team in the 3 years of its existence.

    The time came however that we (read my boss) wanted to have it accessible from outside so our off-site staff would have access. The task was given to Paul and a week or two later the thing was online at which point I took a look at it.

    Turns out Paul does not quite grasp the consept of security. The app run without SSL and despite asking for a username and a password you only needed to enter a 4 letter password to get in. The username was useless. Once inside there was absolutely no escaping user input. Everything ended up in the database as is. And just to be sure that any breach would be as interesting as possible, the app connected via MySQL's root account. The same database holding live data for half a dozen clients.

    A quick email to Paul later I received a reply stating that the matter is not a priority as we are in the middle of a different project. Apparently taking 5 minutes to change the (hardcoded) password and database user for initial damage control was too much work.

    The real WTF however is that after ending up showing this to my boss the guy still works here, merrily typing away on his PC on his quest to make all our lives as interesting as possible. 

     



  • Way to go, picking at your colleagues, being an asshole.

    Feeling better now? 



  • @Kiss me I'm Polish said:

    Way to go, picking at your colleagues, being an asshole.

    Feeling better now? 

     

    Is that you, Paul?
    The whole point of this site is to highlight, laugh, get shocked by and maybe learn from others mistakes.

     

    OT
    Sad to say, but security has a lower priority, at least until someone has misused your service. 



  • @dande said:

    @Kiss me I'm Polish said:

    Way to go, picking at your colleagues, being an asshole.

    Feeling better now? 

     

    Is that you, Paul?
    The whole point of this site is to highlight, laugh, get shocked by and maybe learn from others mistakes.

     

    OT
    Sad to say, but security has a lower priority, at least until someone has misused your service. 

    WTF nr 1: an app running for years using mysql root account

    WTF nr 2: no QA team

    WTF nr 3: somebody with enough spare time to look at what others do on the production server, complain to everyone about it, publish an exploit on theDailyWTF, and not get fired.

    No, I'm not Paul, and I agree it shouldn't be done the way it was, but I hate backseat drivers.



  • Hey, why not post the url here, they we can all play with this insecure code and trash the database.

    Once the page has been removed, and the database restored from backup, the finger-pointing can begin.

    Either Paul will get fired for coding an insecure app, or you will get fired for posting the info here.

    So, do you feel luck, punk?



  • @Kiss me I'm Polish said:

    WTF nr 1: an app running for years using mysql root account

    Read the post again. app was moved to a new server where it started using the root account thanks to Paul

    @Kiss me I'm Polish said:

    WTF nr 2: no QA team 

    We are a tiny company. Even Joel Spoelski had to do without a QA team when he first started a company. 

     @Kiss me I'm Polish said:

    WTF nr 3: somebody with enough spare time to look at what others do on the production server, complain to everyone about it, publish an exploit on theDailyWTF, and not get fired. 

    It's a little hard not to notice that a public site on your server is only using a 4 letter word for security when you're actually using the app as part of your job. After that only a developer who couldn't care less about his job wouldn't take a minute to check on what other blunders the new programmer might have commited. It's not as if this is several thousands of lines of code. Or that I don't know what vulnerabilities to look for in a web app.

    @Kiss me I'm Polish said:

    No, I'm not Paul, and I agree it shouldn't be done the way it was, but I hate backseat drivers.
     

    So do I but if the driver has left the road heading straight for a tree and you were in the back seat you'd speak up. 



  • @DOA said:

     Today I bring you yet another WTF from our latest hire. We shall be refering to him as Paul because he reminds me so much of a certain female individual that has achieved legendary status on this site.

    Paul was tasked with moving a certain web application from our internal server which is only accessible localy to our internet server that is accessible from the web. The application was a typical LAMP job consisting of barely three pages of forms whose sole purpose in life is to log certain tasks the team performs. It was initial built to run on the internal website and such never made very secure or robust. A WTF in itself you might say but it has served its purpose well within our small team in the 3 years of its existence.

    The time came however that we (read my boss) wanted to have it accessible from outside so our off-site staff would have access. The task was given to Paul and a week or two later the thing was online at which point I took a look at it.

    Turns out Paul does not quite grasp the consept of security. The app run without SSL and despite asking for a username and a password you only needed to enter a 4 letter password to get in. The username was useless. Once inside there was absolutely no escaping user input. Everything ended up in the database as is. And just to be sure that any breach would be as interesting as possible, the app connected via MySQL's root account. The same database holding live data for half a dozen clients.

    A quick email to Paul later I received a reply stating that the matter is not a priority as we are in the middle of a different project. Apparently taking 5 minutes to change the (hardcoded) password and database user for initial damage control was too much work.

    The real WTF however is that after ending up showing this to my boss the guy still works here, merrily typing away on his PC on his quest to make all our lives as interesting as possible. 

     

    Heh, I do application security work, and I see crap like that every day. Seriously.

    Just last week, I was asked to look at an application that was ready to be launched. I typed in http://10.whatever/phpmyadmin/ and was dumped into a phpmyadmin console. No username or password. I check mysql.users -- only one account, "root", with a blank password. Yikes!



  • @Kiss me I'm Polish said:

    WTF nr 1: an app running for years using mysql root account

    My uncle's store has a similar problem, everyone (every clerk) is logged into the oracle server with a DBA account, if any of them knew what sqlplus whas or the fact that I removed it from the path, they can access the database and do w/e... Its not such a big risk for him neways so he don't care.

    edit: I did NOT write that program nor do I intend to.

    @Kiss me I'm Polish said:

    WTF nr 2: no QA team 

    That is no excuse for bad programming. In fact that is a reason to write test cases and self-test lots...

    @Kiss me I'm Polish said:

    WTF nr 3: somebody with enough spare time to look at what others do on the production server, complain to everyone about it, publish an exploit on theDailyWTF, and not get fired. 

    Bloomberg has a policy, when you deliver code you give it to a colegue to code review. This has multiple benefits:

    1) Your code is looked over for stupidity just incase you did accidentally or unknowlingly do something stupid.

    2) You colegue knows what you are doing, so you are not the only person who knows this stuff...

    @Kiss me I'm Polish said:

    No, I'm not Paul, and I agree it shouldn't be done the way it was, but I hate backseat drivers.
     

    This is not backseat driving, this is security to no end. Had he been looking over his shoulder and saying "PRESS THE A KEY NOW, NOW THE S, NOW THE S AGAIN..." etc... he would have been it. He is criticizing a terrible idea.


  • Alright, I was harsh on you.

    Apologies. 



  • @Kiss me I'm Polish said:

    Alright, I was harsh on you.

    Apologies. 

    I don't think it was too harsh.

    The OP should have worded his post differently though, because I didn't "get" that Paul had to rework anything other than where the website ran from.  I didn't hear that he had to move the database to a server accessable from the prod server, I didn't get that the connection string would have to be changed to point to the new prod server, I didn't get that Paul was rewriting the input routines to handle SQL injection, or rewriting the authentication mechanism to provide secure passwords vs whatever was being used before.

    Paul may be a moron, but I certainly don't see any proof in the OP.

    Paul was tasked with moving a certain web application from our internal server which is only accessible localy to our internet server that is accessible from the web.



  • @RaspenJho said:

    ... 

    I didn't get that Paul was rewriting the input routines to handle SQL injection, or rewriting the authentication mechanism to provide secure passwords vs whatever was being used before.

    Paul may be a moron, but I certainly don't see any proof in the OP.

    ...

     

     

    Exactly. The WTF here is that Paul didn't do these things on his own in the process of migrating the site to a publically accessible environment. 



  • @rbowes said:

    Just last week, I was asked to look at an application that was ready to be launched. I typed in http://10.whatever/phpmyadmin/ and was dumped into a phpmyadmin console. No username or password. I check mysql.users -- only one account, "root", with a blank password. Yikes!

     

    I would like to say that I haven't seen that, but once again Paul was working on a project. It was a live system holding information on user accounts including information on money they had paid. He had to run some batch SQL statements and since the command line MySQL client was too cumbersome he promptly put the phpMyAdmin folder we had removed from the web server, back in the root folder. Then spent two days mucking about with it during which time it was wide open to the internet. No password whatsoever with default access to root. On the third day I checked and found it online. Apparently he had forgotten it. Ooops. I don't know what went on in his head but I theorize that somewhere back in the reptilian part of his brain he thought that since he was in phpMyAdmin, there wouldn't be room for anyone else.



  • @PerdidoPunk said:

    @RaspenJho said:

    ... 

    I didn't get that Paul was rewriting the input routines to handle SQL injection, or rewriting the authentication mechanism to provide secure passwords vs whatever was being used before.

    Paul may be a moron, but I certainly don't see any proof in the OP.

    ...

     

     

    Exactly. The WTF here is that Paul didn't do these things on his own in the process of migrating the site to a publically accessible environment. 

    There is something good about people who do what they are told, rather than take a 2 hour job and turn it into a week-long engagement, while introducing a plethora of new issues... 

     



  • @RaspenJho said:

    There is something good about people who do what they are told, rather than take a 2 hour job and turn it into a week-long engagement, while introducing a plethora of new issues...
    First, the issues are already there -- there's no need to introduce them.  Secondly, in this example, "just doing what you're told" could very well result in catastrophic losses:

    Once inside there was absolutely no escaping user input. Everything ended up in the database as is. And just to be sure that any breach would be as interesting as possible, the app connected via MySQL's root account. The same database holding live data for half a dozen clients.

    SQL injection holes in an app that uses root on a shared database?  A few DROP DATABASE commands, and Paul's company is going to lose a lot of business.

    To quote an old adage: An ounce of prevention is worth a pound of cure

     



  • @merreborn said:

    @RaspenJho said:

    There is something good about people who do what they are told, rather than take a 2 hour job and turn it into a week-long engagement, while introducing a plethora of new issues...
    First, the issues are already there -- there's no need to introduce them.  Secondly, in this example, "just doing what you're told" could very well result in catastrophic losses:

    Once inside there was absolutely no escaping user input. Everything ended up in the database as is. And just to be sure that any breach would be as interesting as possible, the app connected via MySQL's root account. The same database holding live data for half a dozen clients.

    SQL injection holes in an app that uses root on a shared database?  A few DROP DATABASE commands, and Paul's company is going to lose a lot of business.

    To quote an old adage: An ounce of prevention is worth a pound of cure

     

    Never share a foxhole with a hero...



  • @RaspenJho said:

    There is something good about people who do what they are told, rather than take a 2 hour job and turn it into a week-long engagement, while introducing a plethora of new issues... 



    If a manager or lead developer has to write out step-by-step instructions for every job that's tasked to a report, that report isn't much more useful than a secretary or a data entry clerk.

    Simply because "Paul" wasn't given a specific instruction to implement a specific security measure does not mean that it wasn't part of his job to do.  If I pay an electrician to install some light fixtures, I just expect that he knows he has to actually connect them to a power source, put a switch somewhere in reach, and not leave hot leads lying on the floor or dangling from the ceiling.  Likewise, when I place an order for steak at a restaurant, I assume they know that they're supposed to cook it first and have some idea of how to do this.  If I have to write out instructions for every individual hand motion, I might as well do the job myself.

    As a programmer, whenever you're tasked with [B]any[/B] assignment involving a publicly-accessible service, it's your job to make sure that it's secure.  Furthermore, correct security measures don't "introduce" a "plethora of new issues", they eliminate or minimize the "plethora" of existing ones. 



  • This all depends on exactly what Paul was told to do.  If they just said, "Hey, take this webapp and deploy it on this new server" then it is management's fault for deciding to go live with an unsecured webapp.  How is this guy supposed to know that the program is a piece of crap if he didn't write it?

     On the other hand, if they told him "we use this application internally, but want to make it accesible to others.  Go through it and see what needs to be done in order to make that happen," then yes, Paul should have recognized those holes and patched them up.  He doesn't need step-by-step instructions, but they should have told him that it was either a simple "deploy this" job or a more complicated "get ready for production" job.

    That said, I think it's pretty clear Paul wouldn't know a secure webapp if it kicked him in the teef. 



  •  Couple of issues:

    1) The web servier is responsible for SSL communications, generally the app does not care how it's run.

    2) The password issue... i think the program never had a password (its what it sounds like) because nobody outside their internal network could access it... Thus it was by nature protected by the network

    3) If anyone approaches you saying that we are exposing an internal app to the outside world and you have no idea what to do, get a book or 2 or read a few sites at least.

    4) I assume the company has some sort of QA team? Even 1 dude? Maybe an intern?



  • @Outlaw Programmer said:

    This all depends on exactly what Paul was told to do.  If they just said, "Hey, take this webapp and deploy it on this new server" then it is management's fault for deciding to go live with an unsecured webapp.  How is this guy supposed to know that the program is a piece of crap if he didn't write it?

     On the other hand, if they told him "we use this application internally, but want to make it accesible to others.  Go through it and see what needs to be done in order to make that happen," then yes, Paul should have recognized those holes and patched them up.  He doesn't need step-by-step instructions, but they should have told him that it was either a simple "deploy this" job or a more complicated "get ready for production" job.

    That said, I think it's pretty clear Paul wouldn't know a secure webapp if it kicked him in the teef. 

    I'm glad someone can read between the lines.  Well said Outlaw Programmer.



  • @RaspenJho said:

    @Outlaw Programmer said:

    This all depends on exactly what Paul was told to do.  If they just said, "Hey, take this webapp and deploy it on this new server" then it is management's fault for deciding to go live with an unsecured webapp.  How is this guy supposed to know that the program is a piece of crap if he didn't write it?

     On the other hand, if they told him "we use this application internally, but want to make it accesible to others.  Go through it and see what needs to be done in order to make that happen," then yes, Paul should have recognized those holes and patched them up.  He doesn't need step-by-step instructions, but they should have told him that it was either a simple "deploy this" job or a more complicated "get ready for production" job.

    That said, I think it's pretty clear Paul wouldn't know a secure webapp if it kicked him in the teef. 

    I'm glad someone can read between the lines.  Well said Outlaw Programmer.

     

    Sorry, if he was a consultant and he didn't care about reputation or persuing a career with this company... I would do the same in his position. But currently he is still in that company...

     

    Now I am not for firing people once they make a big mistake, I am however for fixing the mistake and keeping an eye on the person, possibly slapping some sense into him/her.



  • @DOA said:

    Paul was tasked with moving a certain web application from our internal server which is only accessible localy to our internet server that is accessible from the web.

    The important bit here is that the OP told us exactly what Paul's task was.  If I, as a development manager, task one of my developers with "moving a certain web application from our internal server [...] to our internet server [...]", then I expect him to do exactly that.

    I don't care if he uses XCOPY, drag-n-drop, zip-copy-unzip, etc.  What I don't want him doing is taking it upon himself to make code changes because it's the "right thing to do".  If I want him spending time on securing the app, I would have asked him to do so.



  • @RaspenJho said:

    @DOA said:

    Paul was tasked with moving a certain web application from our internal server which is only accessible localy to our internet server that is accessible from the web.

    The important bit here is that the OP told us exactly what Paul's task was.  If I, as a development manager, task one of my developers with "moving a certain web application from our internal server [...] to our internet server [...]", then I expect him to do exactly that.

    I don't care if he uses XCOPY, drag-n-drop, zip-copy-unzip, etc.  What I don't want him doing is taking it upon himself to make code changes because it's the "right thing to do".  If I want him spending time on securing the app, I would have asked him to do so.



    Point well made. However I still feel that he was asked mroe than just "copy". Maybe DOA paraphrased. Obviously paul made a database password entry of 4 characters, and login was not required.

     

    With my team, major ideas get run by everyone so that we can have a chance to say "this sounds like something bad will happen" we rarely have these sort of mistakes unless we did it on purpouse because we were given an extremely tight deadline and no time to actually implement certain things, and even at that point we usually don't make such hacks.



  •  @RaspenJho said:

    @DOA said:

    Paul was tasked with moving a certain web application from our internal server which is only accessible localy to our internet server that is accessible from the web.

    The important bit here is that the OP told us exactly what Paul's task was.  If I, as a development manager, task one of my developers with "moving a certain web application from our internal server [...] to our internet server [...]", then I expect him to do exactly that.

    I don't care if he uses XCOPY, drag-n-drop, zip-copy-unzip, etc.  What I don't want him doing is taking it upon himself to make code changes because it's the "right thing to do".  If I want him spending time on securing the app, I would have asked him to do so.

    I would expect him to go and do it, paying close attention to detail, and when he realized there was something wrong (which there certainly was) I would expect him to let me know about it so I could make a decision on it.

    Saying he should have mindlessly gone about the task is the kind of robot thinking that I imagine causes so many of thw WTFs we see on this site.



  • @MasterPlanSoftware said:

    I would expect him to go and do it, paying close attention to detail, and when he realized there was something wrong (which there certainly was) I would expect him to let me know about it so I could make a decision on it.

    Saying he should have mindlessly gone about the task is the kind of robot thinking that I imagine causes so many of thw WTFs we see on this site.

     

    Robot thinking is the root of all outsourcing :)



  • @MasterPlanSoftware said:

     @RaspenJho said:

    @DOA said:

    Paul was tasked with moving a certain web application from our internal server which is only accessible localy to our internet server that is accessible from the web.

    The important bit here is that the OP told us exactly what Paul's task was.  If I, as a development manager, task one of my developers with "moving a certain web application from our internal server [...] to our internet server [...]", then I expect him to do exactly that.

    I don't care if he uses XCOPY, drag-n-drop, zip-copy-unzip, etc.  What I don't want him doing is taking it upon himself to make code changes because it's the "right thing to do".  If I want him spending time on securing the app, I would have asked him to do so.

    I would expect him to go and do it, paying close attention to detail, and when he realized there was something wrong (which there certainly was) I would expect him to let me know about it so I could make a decision on it.

    Saying he should have mindlessly gone about the task is the kind of robot thinking that I imagine causes so many of thw WTFs we see on this site.

     

     

    Yeah, but "paying close attention to detail" has a different meaning depending on the context.  Again, if this was a simple "deploy this server" task, the details would be: does the site run, do the pages look the same as the internal server, etc.  When you're deploying a webapp, you don't need to look at the source files, you just have to be able to move them around.

    I guess the best case scenario would have been that these guys showed him the webapp he needed to move, he asked a bunch of questions about it, and everyone on the team discovered that it wouldn't be a simple task.  Then they could have Paul make a list of all the things that needed to be changed.  We really need the OP to chime in here to say what the original intent was. 



  • @dlikhten said:

    @MasterPlanSoftware said:

    I would expect him to go and do it, paying close attention to detail, and when he realized there was something wrong (which there certainly was) I would expect him to let me know about it so I could make a decision on it.

    Saying he should have mindlessly gone about the task is the kind of robot thinking that I imagine causes so many of thw WTFs we see on this site.

     

    Robot thinking is the root of all outsourcing :)

     

    Right. If you are going to think like a robot, expect to be replaced by one.



  •  @MasterPlanSoftware said:

    @dlikhten said:

    @MasterPlanSoftware said:

    I would expect him to go and do it, paying close attention to detail, and when he realized there was something wrong (which there certainly was) I would expect him to let me know about it so I could make a decision on it.

    Saying he should have mindlessly gone about the task is the kind of robot thinking that I imagine causes so many of thw WTFs we see on this site.

     

    Robot thinking is the root of all outsourcing :)

     

    Right. If you are going to think like a robot, expect to be replaced by one.

    It just so happens that I think like one... Do I get my own personal robot-assistant? NO? Damn, I thought I'd give it a shot...



  • @Outlaw Programmer said:

    @MasterPlanSoftware said:

     @RaspenJho said:

    @DOA said:

    Paul was tasked with moving a certain web application from our internal server which is only accessible localy to our internet server that is accessible from the web.

    The important bit here is that the OP told us exactly what Paul's task was.  If I, as a development manager, task one of my developers with "moving a certain web application from our internal server [...] to our internet server [...]", then I expect him to do exactly that.

    I don't care if he uses XCOPY, drag-n-drop, zip-copy-unzip, etc.  What I don't want him doing is taking it upon himself to make code changes because it's the "right thing to do".  If I want him spending time on securing the app, I would have asked him to do so.

    I would expect him to go and do it, paying close attention to detail, and when he realized there was something wrong (which there certainly was) I would expect him to let me know about it so I could make a decision on it.

    Saying he should have mindlessly gone about the task is the kind of robot thinking that I imagine causes so many of thw WTFs we see on this site.

     

     

    Yeah, but "paying close attention to detail" has a different meaning depending on the context.  Again, if this was a simple "deploy this server" task, the details would be: does the site run, do the pages look the same as the internal server, etc.  When you're deploying a webapp, you don't need to look at the source files, you just have to be able to move them around.

    I guess the best case scenario would have been that these guys showed him the webapp he needed to move, he asked a bunch of questions about it, and everyone on the team discovered that it wouldn't be a simple task.  Then they could have Paul make a list of all the things that needed to be changed.  We really need the OP to chime in here to say what the original intent was. 

     

    They asked a developer to move it. Not an intern or some lackie. I would expect him to start moving the site and take a quick look at how it works, and what it depends on, etc. It should be fairly obvious that this site is not ready for prime time. I would expect a developer to be able to see that quickly.

     Also, once it was done, I would expect he would quickly give it a few test runs to make sure it was done correctly. According to the OP that is all he had to do to see it was a flaming failure.



  •  I love that "Flaming Failure" I think thats a new tag :)



  • @dlikhten said:

     I love that "Flaming Failure" I think thats a new tag :)

     

    Better be safe, and use all the possible tags...



  • You knew the security was messed up. Why didn't you tell him? For that matter - if he's a new hire and you guys were responsible for a stinking pile of crappy software that apparently doesn't adhere to the most basic security principles (and i count sql injection as one of these) I'd be the one embarassed, internal or not. Seriously, "not very secure" my ass.

    I mean, lets take his POV for a second: You're new, someone tells you through your superior to deploy that PHP app to an Internet-facing server (ASAP i'd guess), you're swamped with work (also a guess) -- what are you going to do? Start a security audit? 

    A couple other WTFs:

    - The app wouldn't be responsible for SSL, that'd be apache in a LAMP stack.

    - You got everything on a single database server. 

    - Your database root account doesn't have a password.

     



  • @Outlaw Programmer said:

    I guess the best case scenario would have been that these guys showed him the webapp he needed to move, he asked a bunch of questions about it, and everyone on the team discovered that it wouldn't be a simple task.  Then they could have Paul make a list of all the things that needed to be changed.  We really need the OP to chime in here to say what the original intent was.
     

    To clear things up Paul was charged with making an small improvement to the app which I did not mention as it is unrelated to the problem. As such however he had to look into the code in detail. He is a programmer (or so he says) , not an intern and when charged to expose the app to the outside world it was taken for granted that he knew what he was doing. The app originally had no login page. It was accessible to everyone in the company and protected by the internal network. He had to add the login mechanism from scratch. He was also told (by me) that the app was made specifically for internal use and that the code needed to be looked at, which he did. Unfortunately it turned out he shouldn't have been let loose on the project without supervision.

    I would not normally let a new developer work on our code without taking a minute or two to check up on him via source control. Unfortunately he was hired by the boss (non-programmer) and I was assured he was experienced. Add to that that we were really busy with other projects and I didn't notice the problem until the app went live and I tried to use it to log some data.



  • @eljo123 said:

    I mean, lets take his POV for a second: You're new, someone tells you through your superior to deploy that PHP app to an Internet-facing server (ASAP i'd guess), you're swamped with work (also a guess) -- what are you going to do? Start a security audit?

    He had a week or two to work on this and only this. Even if he was swamped however I'd expect some sort of warning about the problem. 

    @eljo123 said:

    A couple other WTFs:

    - The app wouldn't be responsible for SSL, that'd be apache in a LAMP stack.

    SSL is enabled on that host. I'd expect him to force its use either through apache configuration, the script itself (can be done) or failing everything else to tell us all to connect to https at that url.

    @eljo123 said:

    - You got everything on a single database server.

    Small company, few clients, no performance problems. What would you suggest? 

    @eljo123 said:

    - Your database root account doesn't have a password.
     

    I don't know where you got that from. The root account does have a password. 


  • Discourse touched me in a no-no place

    @DOA said:

    [...]<font color="#999999"> and when charged to expose the app to the outside world <font color="#000000">it was taken for granted</font> that he knew what he was doing. The app originally had no login page. It was accessible to everyone in the company and protected by the internal network. He had to add the login mechanism from scratch. <font color="#000000">He was also told (by me) that the app was made specifically for internal use and that the code needed to be looked at, which he did.</font> Unfortunately it turned out he shouldn't have been let loose on the project without supervision.</font>

    <font color="#999999">I would not normally let a new developer work on our code without taking a minute or two to check up on him via source control. Unfortunately he was hired by the boss (non-programmer) and <font color="#000000">I was assured he was experienced.</font> Add to that that we were really busy with other projects and I didn't notice the problem until the app went live and I tried to use it to log some data.</font>

     

    I think I can see where things went wrong. Feel free to correct me however.

     

    This post brought to you by the words 'ass-u-me,' 'delegation,' and the number 42.



  • @PJH said:

    I think I can see where things went wrong
     

    Yup, I wont be making that mistake again... 


Log in to reply