Saying anything is a bit dangerous until we know their intentions. Evolution and the process of smarter cultivates dumber for food will continue throughout space. We could well become another cattle ranch in the universe. Its best to say nothing at all because its doggy dog out there in the universe.
Personally I think "Superstar" developers are interested in three things: 1) Decent compensation - shares are a big part of this, they don't like making other people rich off the back of their talent. 2) The difficulty and type of work. Choice of language and how it gets done is pretty important. 3) If the guy in charge is not a technologist but a business person that lack of understanding of development, and especially hackers, is going to mean you have no chance anyway.
In all the projects I've worked on I use one question above all else: "I'm your customer, I need to ship what we have finished today, when can we have it?". if the answer to that question is anything but this afternoon then inheritently you aren't really doing agile (or not doing it very well). One of the back bones of the agile methodology is testing, and since you have to do it every day you automate it. Its this automatation that can give you confidence to release without massive cycles. But in order to get the confidence you need a decent set of tests: 1)Unit tests 2)Integration tests 3)Functional tests 4)Performance tests
Ideally you shoot for 90% code coverage from the unit tests, and the rest is about covering all the major functionality and error cases as possible. Every bug you find starts with writing a test that fails.
As a process this in itself can drastically reduce your turnaround time for a fix and give a team the confidence to release within a few hours. Because if the regression suite runs then you know you haven't broken anything important. Automate more and you should see your turn around time reduce.
Teams doing waterfall support models tend to take a minimum of a couple of weeks to release because they need to do a big block of testing (functional and performance) for all the new functionality and regression of the old software. A common way around that is for emergency quick fixes they branch from the current production and do the fix there with a different track in their team, which gets it out fast. That doesn't work so well for features however because they don't have the same sort of testing effort available and it just slows them down.
Teams doing agile don't need the big testing cycle, and in the worst case need to go to the end of the iteration to have the fix ready (which is normally 1-4 weeks long). They tend to be faster at fixing and don't normally need to resort to going back to the last production, because they do some form of release every iteration anyway.
Sounds to me like a bit more automation and reliance on it might help you greatly. With 20 MLOCS that is going to take a while for the coverage rate to get high. Still every little bit will help.
This is funny and confirms some of my original suspicions.
Previously my company tried to purchase and use a google search engine box. However if you try and buy the google box for your corporate searching needs you will find it impossible to deal with their sales people. They don't offer support, they won't tell you anything. Funnily enough technically if you want to make it work its a doodle.
Google needs to improve its sales drastically if its honestly going to take over the world, technology just is not enough.
The NHS has 9 years remaining of the largest IT project in the world today. The cost is somewhere in the region of £30 billion. The country has been split into different regions, each with a very large IT services company running the show (BT consulting, CSC, Accenture etc). Ther job is to integrate the old systems and bring on new ones to allow patient details to be shared nationally.
It is a massive project, £500 million goes to Microsoft to ensure that they will support TODAYS operating systems to the end of the programme so they can get the hard job of getting it all up and working before the OS gets pulled out from underneith them. Once the system works they are in mantience mode and can port it onto the latest and greatest of the day.
They have some very very old applications that only run in Windows inside of the NHS today, and they are part of the clincial application suite. The truth is that the NHS believes that Windows is unlikely to disappear in the next 9 years, I think that is a fair assumption myself. Unfortunately they have to think that long term since their software really is that complex. Besides it's all about value, redeveloping the current systems that do work will cost more than paying the licence fees.
We are talking about medical software here not your average office user. The NHS is not going to be using Word as much as it is going to be using its clinical applications.
There are not many ports of the clinical apps to Linux, some of them don't even run on windows, heard of HP Non-stop anyone?
Well, I am a professional developer, and I have to say that CVS amongst the 'worst' of the source control systems I've used.
As am I and I have to agree. CVS is impossible to decouple from Unix properly let alone it's glaring security problems.
For a long time I've had in my future projects list a better source control system. I noticed this project a few months back and I've not had any issues with it yet. The fact that it's self serving should give people some idea of just how confident the developers are and I have to say it's well placed.
Eventually everyone will be using this, it's just easier.
Slashdot Mirror
Saying anything is a bit dangerous until we know their intentions. Evolution and the process of smarter cultivates dumber for food will continue throughout space. We could well become another cattle ranch in the universe. Its best to say nothing at all because its doggy dog out there in the universe.
Personally I think "Superstar" developers are interested in three things:
1) Decent compensation - shares are a big part of this, they don't like making other people rich off the back of their talent.
2) The difficulty and type of work. Choice of language and how it gets done is pretty important.
3) If the guy in charge is not a technologist but a business person that lack of understanding of development, and especially hackers, is going to mean you have no chance anyway.
In all the projects I've worked on I use one question above all else: "I'm your customer, I need to ship what we have finished today, when can we have it?". if the answer to that question is anything but this afternoon then inheritently you aren't really doing agile (or not doing it very well). One of the back bones of the agile methodology is testing, and since you have to do it every day you automate it. Its this automatation that can give you confidence to release without massive cycles. But in order to get the confidence you need a decent set of tests:
1)Unit tests
2)Integration tests
3)Functional tests
4)Performance tests
Ideally you shoot for 90% code coverage from the unit tests, and the rest is about covering all the major functionality and error cases as possible. Every bug you find starts with writing a test that fails.
As a process this in itself can drastically reduce your turnaround time for a fix and give a team the confidence to release within a few hours. Because if the regression suite runs then you know you haven't broken anything important. Automate more and you should see your turn around time reduce.
Teams doing waterfall support models tend to take a minimum of a couple of weeks to release because they need to do a big block of testing (functional and performance) for all the new functionality and regression of the old software. A common way around that is for emergency quick fixes they branch from the current production and do the fix there with a different track in their team, which gets it out fast. That doesn't work so well for features however because they don't have the same sort of testing effort available and it just slows them down.
Teams doing agile don't need the big testing cycle, and in the worst case need to go to the end of the iteration to have the fix ready (which is normally 1-4 weeks long). They tend to be faster at fixing and don't normally need to resort to going back to the last production, because they do some form of release every iteration anyway.
Sounds to me like a bit more automation and reliance on it might help you greatly. With 20 MLOCS that is going to take a while for the coverage rate to get high. Still every little bit will help.
This is funny and confirms some of my original suspicions.
Previously my company tried to purchase and use a google search engine box. However if you try and buy the google box for your corporate searching needs you will find it impossible to deal with their sales people. They don't offer support, they won't tell you anything. Funnily enough technically if you want to make it work its a doodle.
Google needs to improve its sales drastically if its honestly going to take over the world, technology just is not enough.
The NHS has 9 years remaining of the largest IT project in the world today. The cost is somewhere in the region of £30 billion. The country has been split into different regions, each with a very large IT services company running the show (BT consulting, CSC, Accenture etc). Ther job is to integrate the old systems and bring on new ones to allow patient details to be shared nationally. It is a massive project, £500 million goes to Microsoft to ensure that they will support TODAYS operating systems to the end of the programme so they can get the hard job of getting it all up and working before the OS gets pulled out from underneith them. Once the system works they are in mantience mode and can port it onto the latest and greatest of the day. They have some very very old applications that only run in Windows inside of the NHS today, and they are part of the clincial application suite. The truth is that the NHS believes that Windows is unlikely to disappear in the next 9 years, I think that is a fair assumption myself. Unfortunately they have to think that long term since their software really is that complex. Besides it's all about value, redeveloping the current systems that do work will cost more than paying the licence fees.
We are talking about medical software here not your average office user. The NHS is not going to be using Word as much as it is going to be using its clinical applications.
There are not many ports of the clinical apps to Linux, some of them don't even run on windows, heard of HP Non-stop anyone?
As am I and I have to agree. CVS is impossible to decouple from Unix properly let alone it's glaring security problems.
For a long time I've had in my future projects list a better source control system. I noticed this project a few months back and I've not had any issues with it yet. The fact that it's self serving should give people some idea of just how confident the developers are and I have to say it's well placed.
Eventually everyone will be using this, it's just easier.