|
|
|
|
|
|
by rhubarbcustard
4614 days ago
|
|
|
Just had a look at that Codeenvy page, it said, "Developers Spend 13 Hours/Week Administering Their Desktop.". That seems like an awful lot, 2 days a week on "administering"? Is this real data from desktop IDE users, if so then this is clearly a huge problem. What kind of things are people spending the 13 hours on each week that is saved by moving to a Cloud IDE? I could see overhead if developers were constantly swapping from project to project to fix bugs and each of those projects had different set ups in terms of where the source code was stored, how it was configured etc. I can't speak for other companies/languages/setups but using one of Eclipse/Netbeans for Java with Maven and SVN/Git is pretty low overhead in terms of configuration for me. For PHP we use SVN, SublimeText and pre-defined build and deploy scripts, which also do not have many pain points. Genuine question: where is the 13 hours spent each week? |
|
|
This does have a tendency to happen in various degrees in larger enterprise environments where configuration problems of the IDE and the systems you are building become costly to maintain. The way we think about it is that organizations have invested in DevOps technologies to automate the entire release process post-commit of the code. But that once the changes make their way out into complex staging / production environments, there are config + code changes that do not synchronize cleanly back into the developer's workspace. So, as the number of commits increases, and the size of the team increases, there are many more synchronizations that need to occur to keep development systems ready for the coders.
So the time suck shows up in mysterious ways: 1) Maintenance of the IDE install, especially with Eclipse which has had plug-in versioning & interoperability challenges at times.
2) Synchronizing configurations across teams, commits, and machines.
3) Collaborative / human costs, from the time spent in having large teams figure out the best way to operate & use their development workbenches consistently.
4) The environment problem, which is partly due to the production environment configuration is not exactly identical to what can be run on the desktop, so managing that in an automated way poses time issues.