StandardPixel.com

One thing that can render any perfectly executed SCRUM planning session useless, is a broken development environment.

Once the backlog has been prioritized, and the team had generated a sensable amount of stories and tasks, teams are energized to start moving those tasks to complete. What is lost when that developer goes back to their desk to find themselves without a db to code against or a login server that just doesent work? A Lot!

What we stand to loose

Sure we all know that these type of outages will cost us backlog, which will translate to time subtracted from our sprint. But what we should fear more is the loss of the momentum that the developer had when he/she finished sprint planning. The developer is now frustrated and will likely not find that lost level of inspiration again. At least not easily. Lets be honest, a developer has very few actual hours of productive time in a work day. Take an avarage 8 hour day and subtract meeting, email, IM, and phone distractions. Lets also consider that most people need a fair amount of time of immersion to reach their most creative state.

Tools make all the difference

All of our distractions require us rely on our tools to be there and ready to go when we need them. This means that we need to spend some serious time planning our tools and how each developer will interact with them through out the sprint. Designers shouldn’t need to interact with code to create designs. Back-End engineers shouldn’t need to hassle with CSS. Also, Front-End engineers shouldn’t need to configure XML files and compile. We have the technology available to make real use of the MVC pattern yet I have witnessed a lot of projects start out with the assumption that everybody can easily run that ANT script or whatever. I can also say that every time I have see this I have seen time being wasted on complex troubleshooting by smart Front-End Engineers and Designers that have been reduced terrible Java troubleshooters.

What to do? What to do?

Excuse my possible ignorance, but in projects where the heavy lifting was done by java and accessed through the magic of web services by clients written in PHP or Ruby on Rails. It cant be a coincidence that these projects had far fewer wasted hours. The pieces are smaller and easier to manage. Each person is working on a smaller chunk of the bigger project that he/she understands enough to easily fix problems. I am sure that somebody would argue that there is far too much processing overhead in such a configuration but i wonder how that weighs against the lost time and creativity without it.

I want to share a pretty cool pattern for collaborating on JavaScript files.A little backgroundIn the application I am working on, we have a need to keep all of our JS in one file that is committed to subversion and included in the application. This one file is updated multiple times by members of our team and as a result needs to be frequently merged. Sure we could use includes of some sort to simplify this process but that has overhead of it’s own. I am sure that a lot of teams have more then one hand in the Java Script cookie jar at a time.The pattern

<script>

//Promoted Code

(function(){

	//Stuff

}())

//John's Code

(function(){

	//Stuff

}())

//Paul's Code

(function(){

	//Stuff

}())

</script>

What does this format offer?

1. Each developer (John and Paul), will have their own closure to keep their development code. This will give them the freedom to create variables without worry of collision with other developer’s code. This also will do garbage collection before running the next developer’s closure.
2. A “Promoted Code” closure exists to hold code that is production ready. This code will be moved from the specific developer’s closure when it’s development is over.
3. Merging is way easier when you know where your code is in the file.
4. Development code is placed after production ready code. This will allow the developers to rewrite objects in the production ready code if needed.
5. Most text editors will let you collapse code blocks in a closure. This will clean up your work area and allow you to better concentrate on your code.

This pattern may seem simple but those are sometimes the best kind. I have noticed a dramatic improvement in my ability to work on these files in collaboration with other developers.