3 ms·

The worst in my days were the very large projects. Besides many other problems. The system's funcional design was written up by analysts talking to the client's

The worst in my days were the very large projects. Besides many other problems. The system's funcional design was written up by analysts talking to the client's middle managers. Neither of those groups had a grasp on how things realy got done on the workfloor beyond the most basic sunny day scenarios. Actual developers and actual users were not allowed to talk to each other as many times the new system would obviously involve some redundancy/displacements in the workforce which needed to be kept under covers and some completely made up at salrs pre-existing system capabilities of the supplier such conversations would 'leak'. Needless to say these projects typically crashed and burned irrecoverably at first contact with production.

jameshart 3y ago
Very first software project I ever worked on professionally gave me a great opportunity to learn this lesson - that managers can not tell you how a task is actually done; you must go and look at how it is actually performed. I was tasked with automating a billing process which, I was told by the boss, just involved copying some data from one database over to another database. Come to look at the actual databases. One of them is denominated in US Dollars, the other in Pounds Sterling. Boss says ‘I’m sure you can just use the current exchange rate’. I decide to go and check how the manual process is currently done. When I ask the person who has been manually carrying out the task what exchange rate they use, they say ‘I take the current rate each morning and add a bit to be safe, because the actual charge will go out in a few days and the rate might change so I don’t want to risk the actual amount billed being higher that day’ (I can’t remember the exact reasoning but it made some kind of sense given the state of international electronic banking at the time). How much is ‘a bit?’ It varies depending on how volatile the currency was looking. They were basically hedging. Boss had no idea that the manual process involved this human judgement step. Taught me to always go and investigate in detail how the manual process is carried out. Where’s the bit where a human being is ‘adding a bit’?

jameshart 3y ago

Very first software project I ever worked on professionally gave me a great opportunity to learn this lesson - that managers can not tell you how a task is actually done; you must go and look at how it is actually performed. I was tasked with automating a billing process which, I was told by the boss, just involved copying some data from one database over to another database. Come to look at the actual databases. One of them is denominated in US Dollars, the other in Pounds Sterling. Boss says ‘I’m sure you can just use the current exchange rate’. I decide to go and check how the manual process is currently done. When I ask the person who has been manually carrying out the task what exchange rate they use, they say ‘I take the current rate each morning and add a bit to be safe, because the actual charge will go out in a few days and the rate might change so I don’t want to risk the actual amount billed being higher that day’ (I can’t remember the exact reasoning but it made some kind of sense given the state of international electronic banking at the time). How much is ‘a bit?’ It varies depending on how volatile the currency was looking. They were basically hedging. Boss had no idea that the manual process involved this human judgement step. Taught me to always go and investigate in detail how the manual process is carried out. Where’s the bit where a human being is ‘adding a bit’?