Cambodia, Phnom Penn, the water festival: Martin Harris
Probably one of the most common mistakes in Software Development is to allow Estimates to become Commitments. I am sure you know the following scenario all too well. The development team is called into a meeting room and asked the following question. We (the management team) have had a look at the estimates, and your tasks on average are taking longer. The insinuation is that the development team is, stupid or perhaps lazy. Worse still, an individual is called in because the stats show their work is “Behind Schedule” as judged by the estimates. The problem is none of this though, the problem is believing that estimates are anything other than an educated guess.
Continue reading Estimates are not commitments! →
Its great to see some competition finally in the surface race. FlatFrog have got a siseable funding according to this gear crunch article. I can see all kinds of uses for this technology, but currently its very expensive. I wish FlatFrog luck in producing a cheaper alternative.
I have found that quite a few programmers struggle to work in a completely test driven fashion. I myself whilst writing tests for many years, took a long time to move over to writing the test first. I think one of my problems was that I always wanted to do my thinking in the implementation class. Recently I have found a great way to leverage the Eclipse IDE’s code complete functions so that its more natural to work from the test class.
The idea is to save effort and time by getting Eclipse to create the implementation side. I have long been used to changing the code, and then using code complete to refactor. For instance you can change a class name or package name, and use CTRL-1 to get a list of options on the code that will not compile. Then use an option to move or rename the class performing the re-factor.
This turns out to be a very powerful technique for driving development from the test.
Try out this simple example I think it makes it more natural to TDD, but I would be interested in your comments.
Continue reading Leveraging Eclipse for TDD →
Every one has a collection of favorite Eclipse templates. I find the simple ones are often the most useful. The examples below create you a static import and finish the method your typing. They even put the cursor in the right place if you need arguments in the method. I am going to collect more of them using the incredibly handy GitHub gist: My Static Import Templates For Eclipse. GitHub gists are great for these kinds of programmer reminders. In addition edits get version control.
Typical Eclipse template for Google Collections
${:importStatic(com.google.common.collect.Lists.newArrayList)}newArrayList();
${cursor}
${:importStatic(com.google.common.collect.Sets.newHashSet)}newHashSet();
${cursor}
To use them, just open Eclipse Preferences: Java Editor: Templates. Add new templates, and give them a name similar to the method. I.e newArrayList. Then your code completion hot key will run the template completing the text your typing in. i.e you type newArrayList [code complete key] and it adds the static, and the rest of the method, placing your cursor at the end of the line. Neat!
Note: See the comment from Yuri below, the above templates are no longer required for static imports. Its possible to configure the Content Assist to bring in a whole type, or member using Prefs:Java:Editor:Content Assist:Favorites. This is better as it scans all possible available methods in the type.
The code you end up with is tidy too:
List myList = newArrayList();
There is another thing I can never remember the syntax for! 
The markup to add the syntax highlight for this blog. Available as a gist: http://gist.github.com/234709
As you achieve more experience with the scrum process, you come to realise that there is very little if anything you can afford to leave out. If your conducting scrum and considering leaving out a practice, its worth considering what is to be gained and lost. So continuing with the scrum and agile theme this year I plan review some of the scrum practices highlighting the benefits and some of the errors that are made. The first of these focuses on the Sprint Review and within that in particular the Software Demo.
Craig Larman in Agile & Iterative Development, A managers guide describes it thus:
Sprint Review: At the end of each iteration, there is a review meeting. (maximum of four hours) hosted by the Scrum Master. The team, Product Owner, and other stakeholders attend. There is a demo of the product. Goals include informing stakeholders of the system functions, design, strengths, weaknesses, effort of the team, and future trouble spots.
Feedback and brainstorming on future directions is encouraged, but no commitments are made during the meeting. Later at the next Sprint Planning meeting, stakeholders and the team make commitments.
“Power Point” presentations are forbidden. Preparation emphasis is on showing the product.
Continue reading Dancing to the tune of the Scrum Demo →
