Ever turned down a project because the clients code base is a mess?
-
:wtf: Starting to wish I had but I'm too poor.
Not turned down, no - but I do put the price up. Only had it twice: once with some very old, very bad Basic (pre VB!) which was to be converted to Windows via VB. Horrible code, horrible job - Ended up flying three hours to Finland, 30 minutes in a taxi, 10 minutes on site, back to airport, 6 hour wait for next plane home...all to press one button on a keyboard... Paid well though. The other time the manufacturer of a coin weighing machine had gone bust leaving the client with a warehouse full of Z80 based machines that didn't weigh new coins. No source code, just what I could read from the EPROM. Priced it appropriately and didn't get it. In the end the machines were sold on when the client went bust as well, but I don't regret my price - it would have been a lot of hassle and guesswork and some jobs I am better off without.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
No, but I'm about ready to fire this guy because his desk is mess. As he's good at his job, I offered him a 10% raise to keep his job and clean his desk.
-
Yes, I have. Most memorable is one where the potential client told me how they had spent 2 years developing an application in-house in a particular language, and they estimated it would take me TWO DAYS to convert the application to a completely different language... read that, rewrite... no conversion possible. I ran away... quickly!!
Quad skating his way through the world since the early 80's... Booger Mobile - My bright green 1964 Ford Falcon - check out the blog here!! | If you feel generous - make a donation to Camp Quality!!
-
:wtf: Starting to wish I had but I'm too poor.
I was asked to look at some software developed in house and to change some of the functionality - I spent a day looking at the code which was a complete mess shoehorning COBOL into areas COBOL should never go then went to my manager and told him I wasn't going to touch it - the only person who could change it with any degree of safety in the time allocated was the person who originally wrote it. That evening, as I was leaving, my manger handed me a letter - it said the choice I had made meant I was incapable of changing the program and therefore unfit for my job or was unwilling to change the program and therefore demonstrating a bad attitude and therefore unfit for my job. I returned the next day and handed in my notice. Later in the day I was given a pay rise and told the bloke who originally wrote the program was to be tasked with changing it.
-
I was asked to look at some software developed in house and to change some of the functionality - I spent a day looking at the code which was a complete mess shoehorning COBOL into areas COBOL should never go then went to my manager and told him I wasn't going to touch it - the only person who could change it with any degree of safety in the time allocated was the person who originally wrote it. That evening, as I was leaving, my manger handed me a letter - it said the choice I had made meant I was incapable of changing the program and therefore unfit for my job or was unwilling to change the program and therefore demonstrating a bad attitude and therefore unfit for my job. I returned the next day and handed in my notice. Later in the day I was given a pay rise and told the bloke who originally wrote the program was to be tasked with changing it.
Good job in not just caving in and taking their bullshit. Your professional opinion was eventually respected, albeit late in the day and you had to threaten to walk. When non-technical managers pester me to get something out of the door before the universally agreed deadline I always say "sure, pull up a chair, get stuck in with us and we'll smash your deadline. let me get you a cuppa before you start coding". The original deadline is immediately reinstated and I won't see the managers again until after the signoff as they are fragile, egotistical creatures who really don't like being put in situations where their complete lack of knowledge could be exposed.
-
:wtf: Starting to wish I had but I'm too poor.
-
Good job in not just caving in and taking their bullshit. Your professional opinion was eventually respected, albeit late in the day and you had to threaten to walk. When non-technical managers pester me to get something out of the door before the universally agreed deadline I always say "sure, pull up a chair, get stuck in with us and we'll smash your deadline. let me get you a cuppa before you start coding". The original deadline is immediately reinstated and I won't see the managers again until after the signoff as they are fragile, egotistical creatures who really don't like being put in situations where their complete lack of knowledge could be exposed.
It was a funny situtation at that company - it was mostly lots of data processing of client files for bulk printing. There was a production team which did all the processing using tools written in COBOL by the development team. I was in tech support (which essentially meant messing about in the depths of the Prime computers we used) - however I had written a data processing/print formatting aware programming language in SPL (Pl/1 derivative) which did everything the COBOL systems did with far more flexibility and with performance 100s of times better. The production team wasn't allowed to use it though - but of course they did - after about 18 months of this the production manager had to own up to why the production team efficiency was massively improved. With the upshot that the MD laid off most of the development team as they had essentially spent the previous 18 months writing programs nobody ever used. The production team thought I was great as they were empowered, the dev team hated me.
-
:wtf: Starting to wish I had but I'm too poor.
Back in the day I used to work in a medium-sized financial institution. Whilst I was working on the core system a new project had started that I had nothing to do with. The history before dev got involved was appalling: The finance department had sold the ability to process card payments. Then they considered the IT requirements. So J Random-Finance-Guy set up a spanky new database (to be fair he did a decent job for a non-specialist). He used an Access database. Then he started to import raw data, things worked OK-ish for a couple of months but he couldn't get the payments to reconcile without a lot of manual adjustment draining the department's resources. Then Access hit the 2GB file size limit and it all stopped working. Then they contacted IT dev. What happened was as instructive of bad managerial decision-making as it was astounding. Instead of putting the most experienced/reliable staff onto this urgent situation they put a fresh-out of uni PhD graduate ("he's clever - he'll manage") on to it unfortunately he'd only written Java. To cover the Java aspect they teamed him with a relatively newly-hired .net dev who, on paper was about as experienced as me (& I started on the beta of .net 1.0). Unfortunately he hadn't worked on anything newer than .net 2.0 and it later showed. The dynamic duo were handed a specification and they went larval. No-body seemed to be keeping an eye on them, every so often I'd have a quick chat just to see what was going on. At one point I realised that it was going wrong. As an example, they were sending .net DataSets across SOAP web services. OK the SOAP part was less of a concern, but they would have made their lives easier with WCF. The DataSet part wasn't sane at all, they did this to avoid converting to OM / Data contracts and the DataSets were large without the "extra" copies. Later I discovered they weren't even using the features of a dataset at the client, and when the client submitted the dataset to the server it was used to update an newly minted dataset which did the database work. Note that both LINQ2SQL and EF were available at this point, and either would have been a more rational fit. I had a quiet word with my manager and I suggested that, perhaps, someone should be monitoring what was going on & I that thought it could fail. Then I thanked my luck stars that I wasn't involved. 6 months elapsed and the deadline arrived: they demonstrated the system. Finance's response was "that's all very good but it doesn't do what we want." Little to no communication
-
:wtf: Starting to wish I had but I'm too poor.
-
Back in the day I used to work in a medium-sized financial institution. Whilst I was working on the core system a new project had started that I had nothing to do with. The history before dev got involved was appalling: The finance department had sold the ability to process card payments. Then they considered the IT requirements. So J Random-Finance-Guy set up a spanky new database (to be fair he did a decent job for a non-specialist). He used an Access database. Then he started to import raw data, things worked OK-ish for a couple of months but he couldn't get the payments to reconcile without a lot of manual adjustment draining the department's resources. Then Access hit the 2GB file size limit and it all stopped working. Then they contacted IT dev. What happened was as instructive of bad managerial decision-making as it was astounding. Instead of putting the most experienced/reliable staff onto this urgent situation they put a fresh-out of uni PhD graduate ("he's clever - he'll manage") on to it unfortunately he'd only written Java. To cover the Java aspect they teamed him with a relatively newly-hired .net dev who, on paper was about as experienced as me (& I started on the beta of .net 1.0). Unfortunately he hadn't worked on anything newer than .net 2.0 and it later showed. The dynamic duo were handed a specification and they went larval. No-body seemed to be keeping an eye on them, every so often I'd have a quick chat just to see what was going on. At one point I realised that it was going wrong. As an example, they were sending .net DataSets across SOAP web services. OK the SOAP part was less of a concern, but they would have made their lives easier with WCF. The DataSet part wasn't sane at all, they did this to avoid converting to OM / Data contracts and the DataSets were large without the "extra" copies. Later I discovered they weren't even using the features of a dataset at the client, and when the client submitted the dataset to the server it was used to update an newly minted dataset which did the database work. Note that both LINQ2SQL and EF were available at this point, and either would have been a more rational fit. I had a quiet word with my manager and I suggested that, perhaps, someone should be monitoring what was going on & I that thought it could fail. Then I thanked my luck stars that I wasn't involved. 6 months elapsed and the deadline arrived: they demonstrated the system. Finance's response was "that's all very good but it doesn't do what we want." Little to no communication
Question: Since when does the manager estimate time remaining on work. Other than the deadline if it can't be helped. But I've never ever heard of a manager telling a dev how long the work would take. At most there's a negotiation if the manager feels it might be too much on the estimation. Or if the dev feels the previous estimate was wrong. I would instantly resign if anyone did that to me. Any barely decent manager should know they have no idea how long implementation takes and to listen to the devs.
-
Question: Since when does the manager estimate time remaining on work. Other than the deadline if it can't be helped. But I've never ever heard of a manager telling a dev how long the work would take. At most there's a negotiation if the manager feels it might be too much on the estimation. Or if the dev feels the previous estimate was wrong. I would instantly resign if anyone did that to me. Any barely decent manager should know they have no idea how long implementation takes and to listen to the devs.
From that you took the estimation process was bad? :) OK it was, but that was the least of the worries, frankly when I moved on to the thing my mind was 90% made up to go (the other 10% was just to see if the rabbit hole was as deep as I though), so I just lived with it until I had my exit strategy. I couldn't figure out the whys of the estimation (the manager had recently been a dev himself so he must have known it was way out yet he behaved as if it was all good). My guess is there was a certain amount of moral hazard in the project and the crystal ball estimation was done on a basis of:
- It kept the upper managers quiet - for a fantastically long time - if you are drowning you don't complain if some keeps throwing a leaky rings at you, as long as you can use them to keep your head above water.
- It allowed the middle managers to keep escalating the commitment, i.e. stopping a politically embarrassing re-write.
- It helped them convince / placate greener devs that joining the project would not be a long term or bad thing. Not that there was much choice.
On point 3 - I knew that the estimate was BS at each stage I heard it, including at joining the project. Part of the problem was we'd discover new flaws as we worked through, not only with the system but the process the system tried to represent, so as we ticked features off the list new ones would appear, but it didn't justify or explain what happened. This remains my worst ever project (and job as it happens). I still wonder at how it was managed and how certain people weren't fired due to their handling of the whole thing (though not, curiously, my direct manager). It was all very instructive.
-
No, but I'm about ready to fire this guy because his desk is mess. As he's good at his job, I offered him a 10% raise to keep his job and clean his desk.
-
:wtf: Starting to wish I had but I'm too poor.
-
I wish I could, but I wouldn't have a job then. Almost every project I've worked on has had at least some code that will infuriate you, and some more that will make you want to find the programmer and beat him to death with bananas. I unfortunately cannot demand that I work only with awesome code, but nobody stops me from writing good code. :)
"Real men drive manual transmission" - Rajesh.
Rajesh R Subramanian wrote:
Almost every project I've worked on has...
So you are saying that there was at least one case where, as an experienced programmer, you came into a legacy application developed by multiple programmers over years and all of the code was excellent?
-
Rajesh R Subramanian wrote:
Almost every project I've worked on has...
So you are saying that there was at least one case where, as an experienced programmer, you came into a legacy application developed by multiple programmers over years and all of the code was excellent?
...
From the previous post[^]:
and some more that will make you want to find the programmer and beat him to death with bananas.
:)
"Real men drive manual transmission" - Rajesh.
