My first computer was a ZX Spectrum 128K +2A, with the +2A meaning some games just didn't work because of the architecture; as opposed to those games that just didn't load for reasons, and those games that did work for 10 minutes then crashed hard. My favourite games on that platform were the Dizzy series. Good times. ;)

Actually literally laughed out loud like a maniachal despot in the office when I read this :laugh:

My favourite "feature" is that deleting a file from the Solution Explorer then performing a checkin doesn't actually commit the delete; you have to open Team Explorer then check in there for the deletes to actually commit...crazy. This also causes complete havok with NuGet which attempts to delete a package that doesn't get deleted so it can't be replaced. I find I have to checkout the whole kit and kaboodle, manually delete the packages, check everything back in, in Team Explorer so packages actually get deleted, then checkout once more, then add the new packages then perform another check in. :wtf:

That happened with a large project of mine; I designed and built a web based dynamic database front end that allowed rapid access to any SQL database on our system and did a ton of other important in house functions; then we got a new marketing guy who decided he couldn't sell it as it was and wanted a new version that completely changed the premise of the original so I had to do six months of rewrites. He couldn't or wouldn't understand why it took so long to make such "small" changes, and the pressure was to make them very fast as he was selling this promised software to clients; the result was a Frankenstein's monster which was a nightmare to debug and make changes to. The kicker was that nobody actually wanted this new hybrid product and it was canned 6 months later. Everyone in the office still uses the original version every day.

When I started my first programming job the team were using legacy C libraries from another company that were old, clunky, terrible to use, full of bugs and required a lot of typing. When creating new programs they copied forward an existing one that did most of what they wanted to do and added a load more code, commenting out any bits they didn't need just in case when it copied forward again the original code would be in there. It was a bit of a mess! I learned their libraries inside out, but instead of saying, all your code is awful why don't you do X, I set about rewriting them a tiny bit at a time and slipping the code into the programs; at first people didn't really get it but after a while (and it was a while) they realised ways of doing things had the same/better resulst and took less typing and started doing it in the different way. Some people don't like change and will cling on to old methodologies and code because it's either what they know and can do, they don't want to put the effort in to learn anything new, that or they think you are usurping them in some way and if they "allow" you to "update" things it implies they were crap in the first place for not doing that ages ago. I'd recommend starting very small or moving to a department/company that likes moving things forward at a faster rate. tldr;

I'll let future me worry about this.

We're a small company and we perform many roles, the MD is very hands on which is sometimes a blessing sometimes a curse, so the marketing manager is the sales manager is the salesman.

How do you think Software apps or services should be sold? For what they are and can do, or for what they could but don't do? The marketer in our office is badly selling our new service; anytime anyone asks him about it he doesn't sell it on any of it's current features he always says something like "we realise it doesn't do this..." insert feature that no-one actually mentioned or asked about, "but we will be developing that in the near future." To me it screams, "we know our product doesn't work at the moment so come back when it does.", which couldn't be further from the truth; it does exactly what it was designed for and briefed to do and does it well and should be sold on it's many merits. You don't hear Sony advertising the PS4 saying, "We realise the graphics are a bit shoddy compared to reality and could be better and will be in the next version...buy the PS4". Rant over. :mad:

Be careful what you wish for. I used to work in a really noisy office, we were a small company and everyone was in the same room so you had account handlers and sales people constantly on the phone with phones ringing non-stop. Then the building was renovated and myself and another developer got our own office, which was sooo quiet and depressing that I would have given anything to move back into the populated office; I started getting moody and frustrated and felt completely isolated especially when the other developer went on holiday for weeks at a time. Eventually we moved into a less populated office and the noise levels were tolerable with headphones, but I'd rather be with people than without them.

Ian M Banks novel Algebraist has a religion called "The Truth" which says that the universe might or might not be a simulation but it we don't know so you have to treat reality as real and get on with it.

Gonna take a hit here... :~ Being a developer in the 'Direct Mail' world, it's worth it for companies to send out vast quantities of printed material because it's cheap and has around a 5% response rate depending on the product.

That's pretty similar to my project, except the sales guy who was supposed to be selling the rebranded product with a few bells and whistles got ideas of grandeur, grabbed the ear of the MD and started making changes...

I'm currently working on a project that was supposed to be 90% the same as an existing product we have, with a new front end and a few new features; however the "business development" team have changed the spec so many times during development that the new product barely resembles the old one. Our idea to use the codebase of the previous product seemed a good one at the time, but now I'd give anything to go back and tell myself to start from scratch instead of writing awful workarounds just to get the new stuff working in time for release - of course this would have depended on us having a decent brief in the first place, but you can't have everything I suppose. :doh:

A new geology app?? :cool:

I claim that, but it's true ;P doing some now.

The first time I used VB.Net I had to rewrite a program that spat out the wrong answer when scoring people against an affluence index after the programmer that wrote it had a nervous breakdown and left (figures). Was not fun.

No good stuff from this one, he's pretty useless :rolleyes:

The sales guy selling our software product just said to me, "sometimes it's like talking to a child", because I gave him the same answer to a question he's asked me at least 4 times regarding what we should do logically with some data; at nearly 30 years old I'm pretty bloody offended. Is it being stubborn not giving him the wrong answer just to appease him? Anyone else had to put up with abuse from non-developers because they just didn't grasp what to you was pretty damn obvious?

You're right, they do pay the wages and whatever name they feel would sell the product is up to them; I think my boss is taking it slightly personally as he came up with the original name etc. and he wasn't consulted about the name change at all.

Our company is being rebranded and we're to fall in line and change the colour scheme of our web application that's currently used internally and is in the process of being sold externally. Unfortunately, the name of our product and the new colour scheme means there may be a trademarking issue with another company who sound/look similar but whose business is pretty much completely different; to pre-empt any legal issues our sales team have decided to rename the software. The original name was chosen 3 years ago and the codebase/application database is built around it; management want the developers and internal users to start referring to it by it's new name (which they haven't even come up with yet), but that's kinda difficult when classes, methods, tables, stored procedures etc. are prefixed/contain the original name. To the development team it will always be known under it's original moniker. Should we have avoided using the name in the code/database and stuck to generic terms?? Anyone else had a similar problem? Having breathed the code for so long I can't imagine calling it anything different when nothing else is changing.

I'll let future me worry about that!

I had to recently rewrite some old utilities we had on Linux as the C source code had gone missing; Python was my go to language.