I find the ones who rush to use the new stuff are the ones who never quite managed to make anything with the old ones. The grass is always greener but also they can blame their lack of progress on the tools.. obviously *this* time it'll be different, just once they've had the right training and given enough time.....

Its when I was offered a job to make a system cope with the customer's increased load that I realised how damaging this is - it was written in Erlang, Ruby and Scala.

Or because some people can't cope with another variation on C++.

They're just tools guys, all these languages coming out, its just like making slightly different style hammers, only hammers don't need any training or lengthy experience to develop decent skills to use.

In such cases you take the requirements document and fulfill it exactly. Then , when the customer says "but its broke and doesn't do.." you pull out the requirements and say "it does everything you asked us to do, anything further is additional development and will be billed accordingly".

Why else do you think government IT contracts cost so much? Why else do you think Agile was invented?

The core problem is that the customer doesn't know how to achieve successful delivery, they need to be educated in fundamental agile processes, of iterative development to evolving requirements (and by evolve, I mean "as the customer figures out what they want".

I used to have similar problems with a customer, but fortunately I had a contact who knew the business. When I received the stupid requirements, I'd phone him and ask what they really meant. Then I'd develop what he said and deliver it to the customer who was always happy, not matter how far from the written spec it was (it helped that my contact was a senior guy at the customer or it wouldn't have worked)

They could actually do that if they gave us something other than "Like" to show support. - like condolences, sympathies, or some such that shows support for the person but doesn't comment upon the situation itself (or even implies that the situation is negative).

Sortof, I find that the situation is:

You work on technology X for a while, you learn it inside and out, and you expect everyone else who is "qualified" knows what you know. but they moved on from that technology a couple of years ago and now only want to develop in Java/Erlang/Ruby/Node/Scala (* delete as applicable as depending on which year this decade you were hiring).

even more mature technologies like .NET are stuffed full of so much churn that no-one really has time to become a master of any of it. Like my mate who was brought into a ASP.NET shop, he learned their tech stack, then one day noticed the trunk had changed a lot, so went to ask the architects who said "oh yes, we decided to move forward with our DB tech, so we're using a repository pattern now". So he goes and learns all about that, does some work on a branch, then goes to merge and... its all changed again. So goes to see the architects who say "ooh no, we decided repository pattern wasn't good enough so we've changed to using entity framework". Now that shop was just stupid, but to a lesser extent this is what is happening all over the industry.

For example, this guy is getting burnt by it.

Whilst I agree that change is necessary to keep things progressing, we're almost in a throwaway culture in ITT where everything we ever did is not good enough and has to be replaced. While there are forces pushing against this (for example, all the people who want to do the big rewrite now know its a bad idea) we still have change via refactoring and flavour-of-the-month tech patterns and frameworks pushed at us.

Only when the industry gets the idea that stable is a good thing and making products is what we should be focussed on doing (ie not changing tech all the time) will this industry be as good career as the other engineering professions.

Then lie. If anyone asks, you just say "oh that, I put it on to prevent identity theft, anyone claiming to be me would not have provably correct information, I always send my correct CV to employers if I apply for a job", leaving out the implicit "fool you for looking at shit on the internet and assuming it was always true".

Now they have flipped it so you get a credit back if you get a response.

Hmm.. so now I'm wondering if its better to keep ignoring those crappy job emails I keep getting to cost the recruiters when they spam me, or to respond to them to stop LinkedIn gaining revenue from my presence.

tricky one....

Mostly pointless though, full encryption for data comms is often worthless - who cares about encrypted comms if all you're doing is looking at pictures of cats. When you're posting subversion messages criticising your local dictator, you need something better than plain old encryption anyway.

Now working with certificate authorities to manage revoked certificates is a good thing, but many of the problems with CAs are a more human problem - until we get to a point where encryption is seen as different to authentication (and even then, my comms with my bank might be encrypted but I need to know that it is my bank I'm talking to as well) and that the CA correctly handed that certificate to my bank, and not some scammer pretending to be my bank. And allowing my bank to verify that it is me that is sending them requests and not some identity thief.

The point I'm trying to make is that encryption isn't the problem that need to be solved, it all the infrastructure around it that does. Mandatory encryption isn't any solution to anything useful.

I think you're confusing the protocol verbs with a heap of javabollocks on the back end.

In most systems GET occurs much more often than POST, and if you're returning to a system after logging off, you'll be doing a lot of GETs just to restore your environment (or page view).

I think a POST+GET optimisation would be nice, but it would be an optimisation, a little like how some DBs have a 'insert, or update if already exists' statement. But you can already return data from a POST, it does break the concept but it works. Just slap the new data in the body and let the client read it if it wants, so maybe the protocol doesn't need any modification at all (your crappy framework code might though, but that's too bad for using those "easy-to-use" frameworks)

Really?
I know mono can produce real native machine code - no VM or such involved, not like Microsoft's ngen that only pre-JITs.

If they have JS compiled to native code too, then that might be interesting.

So, figure out the layers or logical components between each module and then you will be able to chew smaller chunks.

Then, doxygen the whole lot, making sure to use dot to create the graphs for callers and callees. This will let you see the interaction points so you can see what impact a change in one method will have (ie which callers you have to check).

Some people will say "write unit tests" but frankly, it never works with a legacy code base, to effectively unit test you have to write your code differently to how you'd normally do it. You don't have that luxury here. So a good integration test suite should be developed to test the functionality of the whole thing, then you can repeat it to make sure your changes still work. Its not as instant as unit testing (but more effective) so you'll have to invest in a build system that regularly builds and runs the (automated) integration test and tells you the results - and commit changes reasonably regularly so you can isolate changes that end up breaking the system.

The rest of the task is simply hard work running through how it works and understanding it. There's no short-cuts to working hard, sorry.

I do... but then my customers are public sector (police, EMS) who can;t afford to keep replacing their systems every few years.

This is why I advocate multiple tier applications, like the MVC boys but without their "all-in-one project" mentality. Then you can write your server side stuff in a mature, reliable language and give some kids an API that they can use to build flashy GUIs in flash or javascript or whatever fashionable toy they like this month.

And, strangely enough, everybody is happy with this approach - the kids who get to play with new toys, the elders who get to keep a solid application running, and the bosses who get reliability and flashy at the same time!

So throw away your MVC frameworks and templates and embrace the service architecture.

The new Windows is the cloud, or Azure as they call it. They want you to write your GUI for a mobile/web/whatever device and then have it connect to all-Microsoft stuff on Azure, along with Microsoft adverts and Microsoft appstore etc.

They've basically stopped believing that Windows is the only platform that gives them lock-in. Now all platforms will be lock-in!

I think it was brought up in the Google v Oracle case where they had their little legal tantrum over Java copyright.