CruiseControl Configuration for GNU Make

I promised to share the CruiseControl config.xml file we use. Here you go, it is not much of a contribution, but I hope it helps some of you jumping into cruising mode. Our configuration file uses the Exec builder for GNU Make automated builds. Typical examples use Ant in Java environment.



For additional information:

• Martin Fowler, article on Continuous Integration
• Lasse Koskela, Driving on CruiseControl Part1 and Part2
• CruiseControl Configuration Reference

See it in action in my earlier post.

Agile Methodology is not a Religion, it's Just a Passion

I spent three days in Oulu, Finland, attending the XP2006 conference. I have attended other agile conferences, but this was the first time I attended this conference, which was the 7th in series of XP conferences. I have to say I was impressed. The conference is about practitioners to the degree that you really get to sense the belonging in a community of practice. Authors of best selling books, key note speakers, most successful agile consultants in the world, signers of the original agile manifesto, other practitioners from all around the world, all open for discussion on this shared passion, without trying to close a contract before telling more.


I saw that strong passion of doing things right as the combining force of this community.

(Some) People are passionate about religion, too. This is why I think agile thinking is sometimes compared to religion, and comparison of agile and waterfall like methods is said to be a religious war. I saw nothing like religion (at least in a bad sense) in this conference. Instead lots of presentations and hallway talks alike concentrated on balancing methods, applying best from the both worlds, taking existing organization culture into count etc. I do not see this resembling fundamentalist religion at all, do you?



I have to say that in the early days of agile movement I sensed that strong black and white positioning as well. I participated in that. This I believe was the result of so strong survival anxiety after being so fed up with the situation and just wanting to get rid of the old ways of doing stuff all at once. The brilliance of agile methods is manifested in what we are experiencing now. We use continuous retrospectives to improve the method and to adapt it to changing situation. This is possible because practitioners are passionate and enthusiast and put lot of effort into keeping the method fit and healthy.

Sean Hanly from exoftware pointed out in his key note that we must be careful not the end up in the process graveyard with the famous "failures" like RUP, CMM(I), Waterfall and numerous others... By saying this Sean meant that the interpretation of original methodology is in danger to get twisted when number of interpreters increase. When agile development is moving into mainstream we are going to see a lot more practitioners without this passion, but just making the use of a new tool.

There are photos from the conference...

Comprehensive Documentation for Riding a Bike is Difficult

Nonaka and Takeuchi (1995) defined knowledge as explicit and tacit. This view is of course shared with other researchers in organizational learning.

I posted about agile development emphasizing Enable Future Work -documents (as described by James Shore). That holds, but it still does not make creating quality documents easy.

Day after day engineers will arrive at work and launch MS Word alone because they need to document their work for future use. Unfortunately some will open the same tool for documenting what they are planning to do, but this is Get Work Done- documentation (as described by Jim Shore), and we are not talking about that now. At the exact same time same number of engineers will get a copy of such a document to start working based on it. By the lunch time most of them have realized the same old thing; "Just words, not even grasp of what I would have needed, half a day wasted, thank you very much."

I'm reading the Communities of Practice, by Etienne Wegner, for the second time. This time I understand a lot more, but of course I am still not fully getting it. However Etienne gives good example of two sides of knowledge, explicit and tacit. Mr. Wenger used skill of riding a bike as an example. Most of us master this skill, and we can explain it - even fairly well - in paper;






"Push some initial speed, start pedaling and just steer where ever you want to go. "






This is the explicit part, but there is one fundamental ingredient missing in the above document. How do you keep the balance? This is the tacit knowledge part, and it is extremely hard to put on paper. I give you few minutes to think about it...

OK, I tried it also while reading the book, and it reminded me about something we all have experienced.

Agile methods promote simple design to the degree that documentation is not necessary. In embedded world where you want to minimize the material cost you often end up in software and hardware design which are based on intuition. This tacit information is difficult to put on paper, just like the balancing bit of riding a bike. How many times you have been explaining your design to a peer until a bit of detail which has no meaning to you opens the design to your colleague? These obvious facts seldom get identified and reported in paper document created by the original designer individually. As a consequence the document has little or no value. This was manifested with our three-day faceoffs recently. This has nothing to do with agile development methods, since they promote simple design and light documentation?

Quite the contrary. Agile teams work well in preserving and sharing tacit knowledge among members. Daily meetings, retrospective and pair programming(co-design/debugging) are natural techniques for this. Additionally the team commits to deliver work (software/product) which is "done". Done means delivered with just enough and barely sufficient documentation. Agile team should have also shared commitment to deliver necessary documentation, which would enable them to create the documentation in collaborative way. This type of activity is valued in RaPiD7 (Ph.D. pdf), an agile method for creating documents developed at Nokia. Of course the best thing would be to have the "customer" of a document present during the creation work (or that the "customer" writes the document as Vasco Duarte proposes), but this customer for Enable Future Work -documentation is often not available at that point.

The next best thing might just be a collective team responsibility with other project stakeholders and to give it your best shot from multiple perspectives instead of single unmotivated view.

embUnit has some additional features

I posted about my options for proceeding with CruiseControl. A while ago I already wrote a python script which ran the unit tests, and interpreted the results into XML following the JUnit schema. This seemed to be working, but there was one major problem. embUnit output did not include any detail about successfull tests. So I started looking my options again. I took a look at CUnit. It has XML output for its own translator, but this of course does not follow JUnit schema either, so I was not getting any closer.

Then while browsing through embUnit source I made an interesting discovery. The code for embUnit library does not require standard C libraries. This I believe is the embedded part of it. In the distribution there is however additional source code for two different user interfaces; 1) text and 2) XML. These can be compiled into another library (the basic libary comes as binary with distribution), which can be used for host run unit tests. Two libraries can be tied together with nice function pointer usage, similar to what I tried to explain earlier. Everything is coming together beatifully. Example of generated XML report is below. This again does not of course follow the JUnit schema, so I will continue by modifying the CruiseControl XSL translator for it.



To be cont'd...

Celebrating the Complexity - of Life

I just finished reading Stephen Denning book 'The Springboard: How Storytelling Ignites Action in Knowledge-Era Organizations". Easy to read, entertaining material, explaining the power of light touch of storytelling having huge impact. Of course one has to admit that just by reading a book, one won't become the most successful change agent.

I liked the phrasing in the last page:

'...Living instrumentally to achieve explicit fixed objectives is less important than living moment by moment, day by day, appreciating difficulties as much as success. It is a matter of letting go of the urge to control, and the fear that goes with it - learning that the world has the capacity to organize itself, recognizing that managing includes catalyzing this capacity, as well as sparking, creating, unifying, generating emergent truths, celebrating the complexity, the fuzziness and the messiness of living, all the time relishing the sense that almost everything one thinks or knows about the world has turned out to be fake." (Denning, 2001)

I wonder if storytelling is really all it takes. We all know what storyteller Kent Beck achieved with his book.

Original '51 is going to retire

Intel will stop producing embedded processors, including 8051, in 2007. Read what Jack Ganssle wrote about it.

Reserving the Right for Technical Excellence

"...and then the administravite party decided it's time to spend a month repairing and polishing documents, as they seem to be demanded. " I had a nice discussion with two researchers a week ago who have experience in studying NPD processes, also globally. The above phrase is still common. They shared this with a weird smile on their faces. I feel panic closing.

Which documents? For whom? For what purpose? These in my opinion (Vasco Duarte seems to agree) eligible questions all remain unanswered to the date. Of course the idea behind this madness is to offer a project steering committee possibility to control the project (once a year, I'm not even going to get into this). Most of us know that - at best - this is only an illusion of control. Yet, repeatedly the rare resources of a project are streered towards creating this illusion. At the same time people on this same planet are talking about innovative knowledge creating organizations, rapid time to markets etc. Yet some New Product Development can afford spending a month putting 50% obvious facts and 50% of nonsense into form of Word document at the early stages of development?

What do they teach you in courses dealing with panic?
Right, STOP-THINK-ACT

I felt panic, I stopped and I been doing some thinking. What is wrong with this environment? What is there to do? I could apply my (and pretty much majority of developers) favorite "Yes, it is 80% done, and will be complete in - yhm- couple of weeks" -continuity of answers (of course not having a clue what the task in question is). This is not making me laugh anymore, so I propably won't.

Projects that succeed under this type of project management typically have developers which are in "Don't Ask, Don't Tell" mode. I did this for a while. I'm not amused anymore. I do not want to keep up the smoke cover-up. **I want it visible**
After all I think I really need to reserve my right for technical excellence without cover-ups. Always.

Dr. Cooper has acknowledged this and updated his Stage-Gate with seven F's and other guidelines for adapting the model to be more flexible. Phased process models, like waterfall, and early Stage-Gate, survived for 50 years. Transition is ongoing, but all too many organizations remain in denial.

Suddenly at 35 I feel pretty tired, weak and old...

The Seven Principles to Success Revealed

Dr. Robert G. Cooper, the author who introduced the Stage-Gate process model first in 1988, published a Working Paper No.23 recently. In the paper he lists seven New Product Development (NPD) principles that high productivity businesses practice. Data shows that productivity in top organizations can be five times what it is in average company.

The seven principles:

1. Customer focused
2. Front-end loading
3. Spiral development
4. A holistic approach
5. Metrics, accountability, and continuous improvement
6. Focus and effective portfolio management
7. A lean, scalable, and adaptable process

Where have I heard this before?

Get Work Done -Documentation Concidered Harmfull

James Shore writes about two kinds of documentation and agile development.

All of us who have tried to convince someone to value agile methods over plan-driven processes have encountered the phrase "but we need documentation". I really saw the light while reading Mr. Shore's article. It has been clear to me, but division of documentation into these two gatecories gave me the simple structure I have been looking for;

1. Get Work Done
2. Enable Future Work

The following situation is not too uncommon. An embedded system project is getting closer to a process gate. All of a sudden it is time to write documentation because documents are "demanded by the process". This is ridiculous! Process does not demand or want anything, even less likely it is going to NEED anything. Dominating parts in a project system are the people, not the process. What do they NEED in order to progress effectively? That's correct from the back row - communication. Everyone agrees with that, but why is communication so strongly associated with paper document in engineering, or project management? Are we still paying the price of the stereo type created decades ago, that engineers can not communicate? If so, what makes project managers think that engineers could write?

So back to the project. Project has built working prototypes with incremental development and short time-boxing in cross-disciplined engineering teams. Electronic schematics, part lists, price estimates, firmware, mechanical drawings, thermal management results, power handling results, EMC data etc. are available as natural outcome of experimenting. What is missing if we need to COMMUNICATE the project, its status, the risk etc.?

I heard that! "Documentation" you whispered. This is what the process demands, and for some werd reason this is interpreted as Word documentation. So, the team gets into this unproductive mode and writes Word ducumentation at velocity of 2pg/month. Gate passed, everyone happy?

Dead wrong. The first downside is that now the documentation is done. We proceed with prototypes and create more new knowledge on detailed level. This is the spearhead of new knowledge created in this project. Unfortunately since time is wasted at early stages we will be in a hurry towards the end of the project. This means documentation at this crucial stage, at the end, has less focus. Not to mention the frustrated engineers that have already documented a lot without any feedback (the dinosaur process just swallows the papers). It is harder to convince them about the importance of documentation at this later stage. This documentation, which James Shore called Enable Future Work -documentation, remains missing in many so called traditional projects.

The second downside comes from the fact that we actually now have the Get Work Done documentation, but not the high quality Enable Future Work -documentation. This documentation is passed to the next project team as a starting point for their work. This documentation contains obvious facts, which are worthless. More importantly it has flaws and speculations which were found wrong during further experimentation. Unfortunately this new information typically never gets updated into these documents. So there is lots of information that is not true and does not go one-to-one with the actual final design. The new team now spends more time figuring out whether to believe the document or the design. That is if they are not experienced enough to always go with the actual design.

My Three Day Faceoffs -post describes the power of face-to-face communication over paper document in practice.

Get Work Done -(Word) documentation is concidered harmfull.

Agile methods fit firmware as well

David J. Andersson informs us that HP has shown significant productivity gain from agile management techniques in firmware development. There is not much detail available, but here is the short story...

Agile Boot Camp

Pygmalion effect (or self-fullfilling prophecy) is a phenomenon according which the behaviour of group is what is expected. The phenomenon was demonstrated in a study of military training in (Eden, D. Pygmalion without Interpersonal Contrast Effects: Whole Group Gain from Raising Management Expectations, Journal of Applied Psychology, 75, 1990). In the study two teams were observed during their training period. Platoon leaders of one group were told that their men were above averige, while leaders of another group received no information. In reality the two groups of men were equal in potential. However the group that was said to be above average outperformed the other group at the end of the training period.

This supports my belief and observations that to some degree a person has the potential that the leader is willing to see in her.

Based on these ideas I challenge the need for above average (or level 3-5) developers in agile development. Agile framework works also very well as a training camp for junior developers. After all if we said that all developers in agile environment need to be above average, where would all 50,0001% of developers at and below the average go? To marketing? No can do, we need agile customers as well! In these settings the scrummaster's (or XP coach's, or...) role just needs to extend to facilitate this type of learning. Maybe she needs to be more technical than with senior developers, being able to guide with simple design, unit testing, refactoring etc., but it is essential to avoid microleading and accept failure as a method of learning. It is also important to have eyes open for the existing knowledge of junior developers. In most cases it's there enabling two-way learning experience.

Scrum Gives More Time to Surf

"It [Scrum] gives me more time to surf...they bought it...it's great". I think I'm still missing some of the fundamental aspects of Scrum framework. Check if you got it right!

The Firmware "Hassle" with TDD - #3

This post will end theoretical justification of firmware TDD.

Why it would be impossible, or worthless?
"In embedded system we may not have anything to signal the test results with."

Why would it still be worth it, and what kind of hassle is there?
We have to, I seem to repeat myself, distinguish two things in discussion of unit tests in embedded (firmware) system projetcs:

1. host run
2. target run

1. I have been mostly writing about running the tests on host (PC). We are using Cygwin environment. We compile our unit tests with gcc and tests are written on top of embUnit framework. Reporting is done both on screen and as XML.

This article at Object Mentor by James Grenning defines an embedded TDD cycle. This demonstrates the fact that embedded programming is the extreme end of programming. We not only have to worry about all the normal problems in software engineering, but we need to fight these challenges with limited processor resources, poor tools, hard real-time deadlines, stakeholders from other engineering disciplines, usually without formal computer science education etc. This means that having unit test suite alone is not enough for testing the embedded system. The other arrows in embedded TDD cycle illustrate this.

As can be seen in Grenning's article unit testing on host is an important corner piece in the puzzle. Doing TDD has so many other benefits that come as a side products that it is worth the hassle. Unit testing the modules will help you to write clear consistent interfaces and enforce good programming practices.

2. Keeping the modules small and less complex it should not be too much work to port the tests to be run at target environment as well. Nancy has done some work on running the tests in target. In microcontrollers today it is easy to find some kind of serial port to report the results back to PC to be further formatted. Even if you do not have HW pheripheral on board, it's not a big deal to write serial communication driver with bit-banging. This however always needs some arrangements (getting the code to target, resetting the target etc.) In my (limited) experience these little arrangements may just be too much of a barrier to cause the tests not to be run by developers. At least not regularly enough for TDD. Fully automating this at high level is a bit difficult. It needs to be remembered that this would still only partly resolve the problem since the unit test code seldom fits the target memory with production code.

This said, when I get the unit testing on host really going, I will focus on running the same tests on target - and automated. There just is no rush, you cannot get to nirvana over night.

Nancy Van Schooenderwoert will give a presentation at ESC Boston 2006 about their CATS C unittest framework. That should be interesting.

Listen to Evolving Excellence

Kevin Meyer and Bill Waddel have added a "Listen Now" link to their Evolving Excellence blog. You can listen every post as a podcast feed. Give it a try!

Objects and Firmware - Polymorphism

I mentioned earlier that the constraints of object based programming can be overcome in C in order to do full OO programming. This time I will review the simple polymorphing technique in C. This is of course extremely simplified example, but polymorphism in C can be done with function pointers. The example below defines a class called worker which has only one method (function) called doTheJob. We create two entities of worker, but define different implementation for doTheJob. The implementation is selected with the constructor and stored as a function pointer theJob.

***** worker.h *****
  
typedef struct worker
{
  void (*theJob)( void );
} _worker;
  
extern void WORKER_construct( BYTE meIndex,
      void (*function)( void ) ) ;
extern void WORKER_doTheJob( BYTE meIndex );
extern void setPORTA( void );
extern void clearPORTA( void );
  
***** worker.c *****
  
#include "uc_defs.h"
#include "worker.h"
  
worker theWorker[2];
#define me theWorker[meIndex]
  
void WORKER_construct( BYTE meIndex,
       void (*function)(void) )
{
me.theJob = function;
}
  
void WORKER_doTheJob( BYTE meIndex )
{
  me.theJob();
}
  
void setPORTA( void )
{
  PORTA = 0xFF;
}
  
void clearPORTA( void )
{
  PORTA = 0x00;
}
  
***** main.c *****
  
#include "uc_defs.h"
#include "worker.h"
  
void main( void )
{
  WORKER_construct(0, &clearPORTA );
  WORKER_construct(1, &setPORTA ); 
  
  while( 1 )
  {
    if( PORTB & 0x01 )
    {
      WORKER_doTheJob(0); // executes clearPORTA
    }
    else
    {
      WORKER_doTheJob(1); // executes setPORTA
    }
  }
}

I use the WORKER_doTheJob -function to wrap the function pointer in order to keep the interface consistent. I know this adds unnecessary overhead, but hey, we are all artists here and in my opinion it looks more clear.

I have started some series of posts, but not been able to finish any of them. Good news, I will soon use this post as a starting point to finish the TDD hassle -series... :-)

If you got interested in Object-Oriented C Programming (OOCP), here's my tips for a starting point (online):
Evanthelix OO C page
Axel-Tobias Schreiner has done a great job in this book