Thou Shall Maximize Developer Productivity
Software craftsmen are equally concerned with the code they craft and the tools that they use. They arm themselves with Integrated Development Environments (IDEs) like Eclipse or Visual Studio; build tools like Ant and Maven, and unit testing tools like JUnit and NUnit; database tools like Toad, and MySQL Workbench to help them produce reliable software faster than ever before.
When I am intensely directed and focus on writing software where the world around me fades into the background and I am writing code as fast as I can type, I notice when a tool disrupts my ability to stay focused on whatever I am producing. Good tools help you to automate time consuming tasks, great tools work to keep you focused.
The Force.com platform is more than just click and configure. Custom classes and triggers can be written in a language called Apex, which is loosely based on Java, when click and configure does not provide the functionality that you desire. Using an Eclipse Plugin enables the open source IDE to communicate with a specific Force.com organization and give you the ability to write, test and debug your Apex code.
As you write your code in Eclipse, saving a file will trigger the Force.com IDE to save your changes back to the Force.com instance. (You can change this option by turning off the Build Automatically found in the Project Menu, just remember to save your changes to the server later using the Force.com | Save to Server option by right clicking on a specific file or the src folder).
What I have noticed is that the time it takes for the save operation to complete can vary greatly. Sometimes the save operation is quick, maybe 1 second, and other times it can take an excruciating long time of 45 seconds or more. And while I don’t know exactly what causes these delays, I speculate that the longer save times occur within Force.com organizations that have a large number of custom classes and triggers.
Part of this delay is due to the strict requirement for having code coverage of 75% or more in production organizations. Saving a file triggers the unit tests to be executed and if you have a large number of files, it makes logical sense that it would take some time to execute the tests.
Unfortunately, I find these lengthy delays disruptive to my ability to stay “in the zone”. It forces me to think more about the tool and not on the problem at hand. A tool that gets in the way of writing code does not help developer productivity, it hinders it.
My intention here is not to just state a problem but also provide additional thinking on how to solve this productivity issue. I don’t know how feasible this is, but what I would love to see is the ability to bring the force.com cloud down to my laptop. A local sandbox if you will.
Think about this for a moment.
Give us the ability to work offline, on our laptops. Perhaps a virtual machine image that functions just like a Force.com instance in the cloud. A local sandbox. Certain functionality may need to be limited and/or disabled because it wouldn’t make sense. That is understandable.
Not only could that help developer productivity, it would also offload some of the processing required to save, compile and execute the tests on the Salesforce.com servers. And while I don’t know the feasibility for this option, it would certainly be interesting to explore.
What ideas and or practices do you have for increasing developer productivity in the cloud?
Improving Enterprise Development in the Cloud – Part 3
Thou Shall Maximize Developer Productivity
Software craftsmen are equally concerned with the code they craft and the tools that they use. They arm themselves with Integrated Development Environments (IDEs) like Eclipse or Visual Studio; build tools like Ant and Maven, and unit testing tools like JUnit and NUnit; database tools like Toad, and MySQL Workbench to help them produce reliable software faster than ever before.
When I am intensely directed and focus on writing software where the world around me fades into the background and I am writing code as fast as I can type, I notice when a tool disrupts my ability to stay focused on whatever I am producing. Good tools help you to automate time consuming tasks, great tools work to keep you focused.
The Force.com platform is more than just click and configure. Custom classes and triggers can be written in a language called Apex, which is loosely based on Java, when click and configure does not provide the functionality that you desire. Using an Eclipse Plugin enables the open source IDE to communicate with a specific Force.com organization and give you the ability to write, test and debug your Apex code.
As you write your code in Eclipse, saving a file will trigger the Force.com IDE to save your changes back to the Force.com instance. (You can change this option by turning off the Build Automatically found in the Project Menu, just remember to save your changes to the server later using the Force.com | Save to Server option by right clicking on a specific file or the src folder).
What I have noticed is that the time it takes for the save operation to complete can vary greatly. Sometimes the save operation is quick, maybe 1 second, and other times it can take an excruciating long time of 45 seconds or more. And while I don’t know exactly what causes these delays, I speculate that the longer save times occur within Force.com organizations that have a large number of custom classes and triggers.
Part of this delay is due to the strict requirement for having code coverage of 75% or more in production organizations. Saving a file triggers the unit tests to be executed and if you have a large number of files, it makes logical sense that it would take some time to execute the tests.
Unfortunately, I find these lengthy delays disruptive to my ability to stay “in the zone”. It forces me to think more about the tool and not on the problem at hand. A tool that gets in the way of writing code does not help developer productivity, it hinders it.
My intention here is not to just state a problem but also provide additional thinking on how to solve this productivity issue. I don’t know how feasible this is, but what I would love to see is the ability to bring the force.com cloud down to my laptop. A local sandbox if you will.
Think about this for a moment.
Give us the ability to work offline, on our laptops. Perhaps a virtual machine image that functions just like a Force.com instance in the cloud. A local sandbox. Certain functionality may need to be limited and/or disabled because it wouldn’t make sense. That is understandable.
Not only could that help developer productivity, it would also offload some of the processing required to save, compile and execute the tests on the Salesforce.com servers. And while I don’t know the feasibility for this option, it would certainly be interesting to explore.
What ideas and or practices do you have for increasing developer productivity in the cloud?