FitNesse Search & Replace

Uncle Bob announced today the release of FitNesse 20100303. Please grab it from the FitNesse download page. Since I added a new function which I thought over the course of nearly the whole last year and which is not yet finished, let me try to introduce the idea I have with it.

The present

The feature I’m talking about is not very complex nor is it complicated. It’s a feature I was missing over the course of the last two years while working with FitNesse. It’s a simple regular expression based search & replace functionality. Well, thus far there has been a the possibility to do search & replace on the shell-level with regular tools like sed and others. So, what’s new about this? Well, at work we use perforce for revision control. Some while back I wrote a PerforceCmSystem for FitNesse to deal with opening files for writing, for add and for delete. Thereby we can store the FitNesse pages in our revision control system with real ease. Now, I get back to the need for a search & replace function inside FitNesse itself. On the shell we would need to check out each page to change, make the change, then check the changes back in. With search & replace I can now simply hit a button on a page after filling in stuff in two text fields, and then submit the changes made to the pages by FitNesse itself. Version control is done by FitNesse, as well as the change necessary. Great thing!

How does it work?

First of all consider the function to be experimental. There are no checks for consistency between the regular expression and the replacements. This made the implementation really easy, and there already some changes waiting for the next release to implement. That said, you will find two new text boxes on the refactoring page. In the first box you can enter regular expressions according to the description from the Java API documentation. You may use grouping enclosed with (), etc. On the second box you can insert a replacement, maybe referencing groups from the pattern in the first box. So, let’s walk through an example. Say, I have got some test pages, where Peter is used as the standard user. Now, for equality reasons, I would like to change Peter to Petra. Then I enter Peter in the first box, and Petra in the second one, hit the search & replace button, and watch the result popping up.

There is one thing you have to keep in mind. Search & replace works on the page hierarchy level. This means that any page below the page where the refactoring button was pressed, search & replace will work on. On any level above that nothing will be changed. So, you have to be aware where you start your replacements.

The future

There a two main streams for the future on FitNesse and refactorings. First, search & replace needs further evaluation and needs to grow. Uncle Bob suggested to include a two page flow, where I get all the results from the search on a second page and can choose among the replacements I would like to have – or as it is today, to replace all. This is already planned on pivotal tracker, and I would be happy to learn something new while implementing this.

Second thing I see coming is a refactoring for the tables inside FitNesse. With the underlying classes it’s very easy to write a custom refactoring for FitNesse that exchanges for example two columns from a table. For the following table:

a b c
asdf qwer yxcv

I might provide to exchange column a and c, resulting in the following table:

c b a
yxcv qwer asdf

So, I would be happy on feedback on this feature and the future of refactoring in tools like FitNesse. The column replacer would be a neat feature, but I hope it’s just the beginning of a refactoring tool for wiki-pages. So, please leave me a comment what you think about it, or how you think search & replace might be used as well.

Are we Agile, yet? – Revisited

Abby Fichtner – The Hacker Chick – wrote a blog entry asking (and answering) Are we agile yet?. In essence it relates the Poppendieck’s seven principles from Lean to other Agile methodologies. Since I’m currently finishing up the Quality Software Management series from Gerald M. Weinberg, I got to know about the importance to know about many models for developing software. So, I decided to expand the thoughts of her seven key points beyond Lean, Kanban, and Scrum and strive over some of the most common Agile methodologies. In this blog entry I’m going to re-visit the seven principles and expand the view to XP, and Crystal.

Eliminate waste

Eliminating waste is at the heart of Lean. Similarly in Scrum the team is asked to just implement the items from the backlog with the highest priority. In Agile Estimating and Planning Mike Cohn describes very well, that the the items with the highest priority are realized from the backlog first. Thereby the team achieves a software product with the highest business value. In QSM Vol. 4 Jerry Weinberg denotes it as the 90% of the implementation that delivers 99.9% of the value to the customer. Similarly, by working in this manner you will drop the meaningless features if you need the core functionalities sooner. Meaningless features in the product backlog are then of course an instance of waste.

XP favors the principle of simplicity. There is an implication to eliminating waste here. Everything that is not simple, is wasteful and deteriorates the process for maintenance. By focusing on simplicity, waste is eliminated by definition. Similarly, Cockburn separated Crystal into families of methodologies to keep them simple and eliminate methodology weight from smaller teams while still preserving necessary and relevant ceremony for larger teams. Crystal therefore eliminates waste by structure of the methodologies.

Build Quality in

Tackling the quality matter for the several Agile methodologies is a bit more demanding. First, test-driven development from XP is one of the most difficult Agile practices, but it is also the most copied one. Cockburn speaks about it for Crystal, similarly it is in wide-spread use in vital Scrum and Kanban practicing teams. The Pragmatic Programmers speak about quality from the start. Pair Programming from XP is a way to review code as you go. Likewise, customer involvement from XP together with specification workshops and specification by example bring in quality right from the start. These practices are in wide use among methodology boundaries and are shared in the whole Agile community.

Create insights

Personally, I rephrased this to “create insights” from “create knowledge”. The single-most Agile practice that everyone recommends is taking the time for reflection. There are several names for the same concept. Sprint Reviews in Scrum, Kaizen in Kanban, Retrospectives in XP, Reflection Workshops in Crystal all generate insights from a time-boxed interval of the project, and set the team up for knowledge from their past iterations or sprints. Over time, the team piles up more and more knowledge created from projects, tried out ideas to improve the process for themselves. “If you need to adopt just a single practice, use retrospectives, the rest will follow up.”

In addition to regular reflection, transparency is the key to visible progress. Information Radiators, Task Boards, Story Boards, build monitor are all ways to make progress visible among Agile teams. Combined with the insights and actions from the last retrospectives, they set the team up for success. Not only in Scrum and Kanban, but also for XP and Crystal.

Last, involvement of the customer from the start is a key success for visible progress. Showing results from the last work increment to the customers and stakeholders in regular intervals is a vital part of XP, Crystal, and Scrum. Getting the feedback from the people supporting the project also sets you up to build quality in.

Defer commitment

Similarly as the previous two points, deferring actions to the last responsible moment is a common theme across Agile methodologies. The principle is in play for programmers building the programs incrementally and iteratively, for iteration planning in XP and Scrum, and even for process improvement actions to foster.

But I recommend to take care here. “Defer commitment” does not mean in any way to not commit to anything at all. The team commits regularly to the next increment to the product they grow. The team calls this the iteration, the pulse at which Agile software development operates. Like a living system, the iteration is the heart of Agile development methodologies. Accompanied with reflection about the last pulse, the Agile development organism adapts to new situations and sets themselves up for the vital learning in the team. Crystal, XP, Scrum and Pragmatic Programming names this deferred commitment. It’s even a part of Software Craftsmanship, which I personally would include to the Agile methodologies – though they made a value-shift based on the initial manifesto.

Deliver fast

Here I also need to add a note: Don’t confuse speed with progress. Note the ambiguity for delivering fast. One way to deliver fast is to deliver at a high speed, while coding yourself into the corner of Technical Debt. This is not meant. Instead, you have to keep an eye on the delivery for today, but also set yourself up for tomorrows delivery. A sustaining pace is vital for todays fast – in terms of progress – delivery, and for tomorrow’s. This insight is at the heard of the Cooperative Game principle from Cockburn and underlying the Crystal methodologies.

In fact, one key motivation for the Software Craftsmanship movement at the end of 2008 was the realization that the “setting yourself up for the next round” became a common practice for fast delivering teams. The key is not to deliver fast today, but to deliver fast today, tomorrow, next week, next year, and even in ten years. Over the course of the last decade with the widespread of Agile methodology this seems to have been forgotten.

Back to methodologies, the iteration pulse in Scrum, XP, and Crystal creates the basis for the sustainable pace. The team sets themselves sets up for a continuous flow of value for customers and stakeholders. Thereby a steady flow of progress with indeed fast delivery is achieved.

Respect people

XP defines the XP team generating the respect for the people on the project. Similarly Crystal evolved out of the respect for people. Setting up self-responsible teams that take care and pride of their process for themselves, enables them to deliver steady value and – as a side-effect – increases productivity. Leaving people with the choice for their own process, getting them motivated to succeed the project, and rewarding them for their achievements is a core Agile aspect. And there is nothing more rewarding to show a working piece of software to your customer and get the appreciation from them – at the end of every second week or every month.

Optimize the whole

Reflection workshops take insights from the team and action items from good reflection workshops create an optimizing whole. Putting the people together in cross-functional teams, removal the boundaries from decades of separate working, enables everyone on the team to see the whole picture of the project. For example, planning poker puts together the whole team to work out the scope of the next increment. Specification workshops put business analysts, developers, and testers together with customers to get their needs and form a common understanding of the product to build. One key aspect of Crystal is the easy access to expert users among teams. Without this all encompassing view on the project as a whole, there wouldn’t be a way to optimize it as a whole. In companion with self-organizing teams, this optimization becomes natural in Agile projects.

Finally

One final point I would like to raise. Why does it matter for you to be Agile or agile? Instead of hunting for a place or time you may call “Agile”, rather ask yourself, “does it work for you?” If you can seriously without any doubts state, “yes, it works for me and all my colleagues, stakeholders and customers”, then you shouldn’t bother. If not, asking “are we agile” won’t help you either, since you don’t know if you need to be Agile in your situation, of if you should be somewhere else. Following a practice or notation just because it’s the latest hype, is cargo-culting. Instead you find out where you want to be, and plan to get there, but to set yourself up to anticipate any directional changes while trying to get there.