Luke Hohmann hat seinen Artikel “Why Prioritizing Your Product Backlog for ROI Doesn´t Work” [1], beschrieben, dass es um eine Backlog Item priorisieren zu können, notwendig sei: “identify stakeholder preferences, understand which backlog items align to corporate strategy, and demonstrate which backlog items drive profit.”

Ob man mit seinen Ideen, die er sehr ausführlich darlegt, übereinstimmt, oder nicht, en Read more ...

Look around you and you'll find that many organizations claiming to be Agile or "doing Scrum" are actually doing something else. I call it W-agile. They dress up the work in the trappings of XP and Scrum but really work in nested mini-waterfalls focusing on one big delivery at the end of the project. Often, developers are working in isolation from their business stakeholders which misses the original agile vision. For example, this week I ran a class on Planning with User Stories. Questions asked (see pic) by the people on the course hinted that they were working in a...

Alan Atlas has a recent blog post where he discusses agile, lean and scrum and suggests that you can't truly achieve agility unless your company is fully committed to it which differs slightly from my experiences.

Alan makes a valid point that we're not really following an approach just because we use all the practices:

Many people make the mistake of viewing Scrum and Agile and Lean as sets of practices. “If I do kanban, I’m Lean.” “If I do sprints, I’m scrummy.”

It's quite easy to put our work up on a story wall, run a daily standup and unit test our code and not really get the full benefit that those practices are supposed to give us.

As I've mentioned before though I think it is part of the learning process that we start out focusing on practices and not principles.

However, at some stage we need to start thinking for ourselves about the value those are giving and making adjustments to them if we're not seeing much value i.e. we need to look beyond the practice and to the principle or outcome that we are trying to achieve by using that practice.

The part of the post which is different to my experiences is this bit:

So I smile to myself (I think it’s to myself) when I hear management say things like “We’ll never be totally Agile in this company. There will always be waterfall projects.” I smile because what that really means is that they’ll never be Agile at all.

I haven't heard conversations like this before but I think it is still possible to deliver software in a team working in an 'agile' way even if the rest of the organisation which that team operates in follows a different approach.

It won't be as smooth sailing as if the whole organisation buys into the lean/agile approach and there will still be some reporting and bureaucracy that you need to deal with but it's not a lost cause.

My colleague Lindy Stephens and a couple of others covered some of the issues around project governance in the enterprise in a ThoughtWorks QTB in Sydney last year. The slides from that presentation are available on slideshare.

If your company is not fully committed to agility then you won’t achieve it, and your results will be a self-fulfilling prophecy of unrealized potential.

Even if an organisation decides that it wants to be agile I think it still takes time to get used to the approach and it always seems to take a few successful deliveries to see that some of the worries that heavy weight processes and paperwork try to protect you against are not necessarily valid.

I've spent a lot of time being indignant that people didn't buy into the agile approach but the more I spend time in different organisations the more it becomes clear that even for the people with the best intentions in wanting to learn this approach it will still take time to get there.

I'm coming to the conclusion that it's a good thing that people have some level of skepticism because it forces you to really understand why an agile approach is more effective and then try and persuade other people of that.

It's also helpful to note that it makes sense to vary our approach depending on the context that we're operating in. For example if the team is distributed across different cities then we might have more written documentation than with a co-located team.

It's very rare that an organisation or group of people will just 'get it' straight away – in many ways it's quite an iterative/incremental journey.

Administrative Assistant Wanted 

Part-Time

Agile Learning Labs is a small startup company in Foster City that delivers training and coaching to project managers, executives and software developers. We are looking for a part-time administrative assistant who relishes being part of a small team as much as we do. You will be responsible for managing the infrastructure of the business, from bill-paying and document preparation to providing support for the activities of the company's CEO, publications editor and salesperson.

 The position is part-time. Growth is part of our plan and this job could become full time in the future, but we’re also open to a long-term relationship with someone for whom part time work is a lifestyle choice.

Job Description, Activities, Responsibilities

• Client invoicing and billing
• Arranging venue, catering and other logistics for events
• Maintaining the website's event calendar
• Monthly email newsletter
• Scanning, transcribing, and summarizing workshop feedback forms
• Driving, to pickup office supplies, drop off promotional materials, etc.
• Maintain and restock training kits (office supplies, printed materials)
• Field email and phone requests regarding public training class details
• Prepare documents for approval by certification organizations
• Copy and distribute fliers
• Make travel arrangements
• Do scheduling for coaching clients
• Run errands
• Basic maintenance on office equipment (replace toner or ink in printers)
• Proof-read and test website pages
• Tracking receipts and expenses
• Contribute ideas toward the continuous improvement of the business
• Post workshop announcements to various websites and other promotion and publicity channels

Required Skills

• Excel, Word, and PowerPoint
• Stickler for details
• Has a car, insurance
• Good phone and email skills

 

Additional Skills - willing to train

• Quickbooks
• Blogging/Content Management Systems
• HTML

More Background

Our startup is at an important juncture; to date we have all pitched in on administrative tasks to keep our business running smoothly, but none of us is a strong administrator. This means you’ll have our gratitude, respect and cooperation as you take over these functions. Hiring this position is a milestone for us, as it will allow us to focus our energies where our own talents lie and step up the growth of our business, and we can’t overstate how much we value this new role and appreciate the expertise it requires.

As for your background and qualifications, we’re looking for confidence and maturity, a knack for organization and a passion for meticulousness. You might be a former copy editor who wants to make a career change. Or you might be a retired bookkeeper who wants to stay active. You could be a junior college student, or maybe you’re returning to school to get your MBA after raising three kids, or maybe your kids finally started school and you want to spend a few hours a day with people who use four syllable words. Your background and experience can take many forms, from running your own business, to heading a volunteer committee.

We’re looking to hire a real person, not just a set of skills or credentials, so your cover letter is just as important as your resume. Tell us a bit about yourself, and we’ll take it from there.  Send your resume and cover letter to: IWantToWork@AgileLearningLabs.com

Authors: Tim Ottinger and Jeff Langr
Font: Burst My Bubble

Programming pundits often decry the dismal state of code in the world. We hear speakers demand professionalism or a more craftsmanlike value system, rigorous certification, etc. In response to these very demands we find contradiction of these very concepts. The argument is frequently made that whether code is "good" or "bad" is subjective and situational. We beg to differ.

To promote a shared set of programming values, we propose these seven virtues of code:

• Working, as opposed to incomplete
  A program that works is simply superior to one that doesn't work. We contend that a working program now is of higher value than one that might work some day. To this end, incremental and iterative methods (such as agile methods) push us to complete small features as soon as possible, with improvements and expansions to follow.
  We ensure code is working by writing tests before and after writing code as we consider more success and failure modes. We can tell code is working by running the tests and by using the software.
  
• Unique, as opposed to duplicated
  The worst thing we can do to working code is to duplicate it. Copies and near-copies scattered willy-nilly across the code base makes code difficult to maintain. We struggle to eliminate duplication each time we refactor in our red, green, refactor cycle.
  A dirty software industry secret: Many "stepback" or "regression" errors are not really re-broken code, but are instead examples of fixes to duplicated code.
  We can tell that code is duplicated visually (common paragraph structures) or by the use of duplicate detecting tools like Simian.
  
• Simple, as opposed to complex
  Simplicity here refers to the number of entities, operations, and relationships present in any particular routine/function, and not to the readability of that module (which we call "clarity").
  The best way to increase simplicity is to use simpler structures and algorithms. Reducing complexity in this way often translates to improved runtimes, smaller code size, and easier optimization.
  We can also improve simplicity of one routine by extracting methods so that a series of manipulations becomes a single step as far as all of its callers are concerned. By moving the extracted methods to the appropriate classes, we also further develop the type system. After extraction, the code still takes all of the same steps, but those steps are evident in far fewer places in the code. The extracted methods are also simpler because they are unencumbered by their original context, a fact which aids us in finding yet simpler algorithms and structures.
  Such simplifying code migration is at the heart of object-oriented design.
  
• Clear, as opposed to puzzling
  The meaning and intent of code must be obvious to the reader. Code misunderstandings generate errors. Confusion over code creates delays.
  While high-level languages make it easy to see what code is doing, there is still an art to producing code which communicates its goal and intent. The consensus of multiple readers is nonetheless a reasonably consistent measure of clarity. Therefore, the most reliable way to make code clear is to have multiple colleagues reading it.
  When one sees an improvement in readability from merely renaming variables, classes, or functions it is because one has improved clarity without changing any of the other virtues of the code. Clarity is further amplified by other virtues such as simplicity and brevity.
  
• Easy, as opposed to difficult
  Adding and modifying code should not be an arduous process. Ease is largely a matter of how much code must be typed in how many places, and how much configuration must change. In a particularly ugly code base, the easiest way to get code working is to implement a hack in an inappropriate place. In a truly clean and simple code base, putting a correct design into place is often as easy as a hack. Uncle Bob Martin has stated that design has degraded when the doing "the right thing" is significantly harder than making "an ugly hack."
  
• Developed, as opposed to primitive
  A primitive system is not necessarily simpler (fewer parts), nor easier (less thinking and typing), nor more clear than a developed system. Primitive code tends to be characterized by Duplication, Feature Envy, and Primitive Obsession code smells. These make a primitive solution more complex, more difficult, and less clear than one built with a well-developed type system.
  In an object-oriented system, the developed type system of an application provides well-thought-out classes whose methods make continued development easy.
  A system is well-developed when functionality appears to be just where one might expect it. String methods on strings, account methods on accounts, and button activations and the like merely make calls on "business objects."
  
• Brief, as opposed to chatty
  It is valuable for code to be as brief as possible without sacrificing other virtues. This is part of the reason that language tools like LINQ and list comprehensions and closures have become so popular of late. All programmers, including the one who writes it, benefit from writing and reading less code (as long as this smaller amount of code is otherwise clean).
  Code that is long and chatty is much more likely to contain hidden errors. An overly cryptic method is likely to be misunderstood. Either one is hard to take in at a glance and understand.
  Playing "programming golf" is actually a meaningful activity. If one can make the solution to a problem smaller without sacrificing clarity (or indeed may improve clarity by reducing the solution to a smaller form), then one is reaching a more brief form. The distance from an ideally brief, clear form is unwanted verbosity (chattiness).

My colleague John Hume wrote an interesting post about his experience with the 'const' keyword in ActionScript where he describes the problems with trying to capture a loop variable in a closure and then evaluating it later on in the code.

Since ActionScript and JavaScript are both dialects of ECMAscript, this is a problem in JavaScript as well, and is due to the fact that variables in JavaScript have function scope rather than block scope which is the case in many other languages.

This problem would tend to reveal itself in code where we try to capture a loop variable in an anonymous function and use it later on, like so:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) {
       x[i] = function() { return i; }
    }
    return x;
};
 
var values = getValues();
for(var j=0; j < values.length; j++) {
    console.log(values[j]());
}

We might expect that to print the sequence of numbers 0-9 on the screen but what we actually get is '10′ printed 10 times.

There are a couple of things that I initially found strange about this:

1. Why doesn't it print out the numbers 0-9?
2. Given that it doesn't do that why does it print out '10′ 10 times instead of '9′ 10 times?

The answer to the first question is that 'i' gets assigned a new value on each iteration of the loop and we don't evaluate 'i' until we evaluate the anonymous function on line 11.

The value when we do evaluate it would be the last value that it was set to by the loop which in this case that would be '10′ because that's the value that 'i' has to be in order for the loop to terminate.

This is actually a problem in C# as well – the following code will output '10′ 10 times as well:

[Test]
public void ClosureOnTheSameValue()
{
    var values = new List<Func<int>>();
    for(int i=0; i < 10; i++)
    {
        values.Add(() => i);
    }
 
    foreach (var value in values)
    {
        Console.WriteLine(value());
    }
}

Again we capture 'i' inside a closure and since we only evaluate that value when it's actually used it will always refer to the last value that 'i' was set to which in this case means that it will always output a value of 10.

To fix this in C# we could just create a temporary variable – something which Resharper will actually suggest to us:

[Test]
public void ClosureOnDifferentValue()
{
    var values = new List<Func<int>>();
    for(int i=0; i < 10; i++)
    {
        var idash = i;
        values.Add(() => idash);
    }
 
    foreach (var value in values)
    {
        Console.WriteLine(value());
    }
}

This works in C# because variables have block scope which means that we have a new version of 'idash' for each of the functions that we add to the 'values' collection.

Sadly the same trick doesn't work in JavaScript because variables have function scope in Javascript:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) {
       var idash = i;
       x[i] = function() { return idash; }
    }
    return x;
};
 
var values = getValues();
for(var j=0; j < values.length; j++) {
    console.log(values[j]());
}

The 'idash' temporary variable that we created to try and solve the problem gets assigned a new value in each iteration of the loop because that variable is only declared once for the whole function.

The code above could be written like this to make that clearer:

function getValues() {
    var x = new Array();
    var idash;
 
    for(var i=0; i < 10; i++) {
       idash = i;
       x[i] = function() { return idash; }
    }
    return x;
};
 
var values = getValues();
for(var j=0; j < values.length; j++) {
    console.log(values[j]());
}

As John points out:

Here's something I either never knew or at some point forgot about JavaScript: variables are lexically scoped, but only function bodies introduce new lexical scopes.

In this case we actually end up printing '9′ 10 times because that's the maximum value that gets assigned to 'idash'.

One solution is to create a temporary variable inside an anonymous function that we execute immediately, like this:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) {
        (function() {
            var idash = i;
            x[i] = function() { return idash; } })();
    }
    return x;
};
 
var values = getValues();
for(var j=0; j < values.length; j++) {
    console.log(values[j]());
}

Now 'idash' is scoped inside the anonymous function and we therefore end up with a new value each time like we want.

Raph pointed out that we could achieve the same thing in a simpler way with the following code:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) (function(i) {
        x[i] = function() { return i; };
    })(i);
    return x;
};
 
var values = getValues();
for(var j=0; j < values.length; j++) {
    console.log(values[j]());
}

Here we define a for loop with just a single statement so we can lose the '{}' and just call an anonymous function passing in 'i'.

Of course this example is truly contrived but I wanted to pick something simple enough that I could try and follow exactly how it worked.

I'm not entirely sure of the terminology around closures and scoping so if I've described anything incorrectly then please correct me!

Please follow link here: http://prezi.com/gc0m9zvmjb0q/

This downloadable PDF flyer describes the Scrum Alliance Registered Education Provider program.

The following application is for organizations wishing to apply to become Scrum Alliance Registered Education Providers.

During a flurry of tweets and blog posts about whether or not ATDD is a good thing, I posted a blog on Stickyminds with my opinion. I’ve gotten some great comments, please add yours!

Previous posts in this series:

• A Primer
• Aggregate Construction

One of the common themes throughout the DDD book is that much of the nuts and bolts of structural domain-driven design is just plain good use of object-oriented programming.  This is certainly true, but DDD adds some direction to OOP, along with roles, stereotypes and patterns.  Much of the direction for building entities at the class level can, and should, come from test-driven development.  TDD is a great tool for building OO systems, as we incrementally build our design with only the behavior that is needed to pass the test.  Our big challenge then is to write good tests.

To fully harness TDD, we need to be highly attuned to the design that comes out of our tests.  For example, suppose we have our traditional Customer and Order objects.  In our world, an Order has a Customer, and a Customer can have many Orders.  We have this directionality because we can navigate this relationship from both directions in our application.  In the last post, we worked to satisfy invariants to prevent an unsupported and nonsensical state for our objects.

We can start with a fairly simple test:

[Test]
public void Should_add_the_order_to_the_customers_order_lists_when_an_order_is_created()
{
    var customer = new Customer();
    var order = new Order(customer);

    customer.Orders.ShouldContain(order);
}

At first, this test does not compile, as Customer does not yet contain an Orders member.  To make this test compile (and subsequently fail), we add an Orders list to Customer:

public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Province { get; set; }
    public List<Order> Orders { get; set; }

    public string GetFullName()
    {
        return LastName + ", " + FirstName;
    }
}

With the Orders now exposed on Customer, we can make our test pass from the Order constructor:

public class Order
{
    public Order(Customer customer)
    {
        Customer = customer;
        customer.Orders.Add(this);
    }

And all is well in our development world, right?  Not quite.  This design exposes quite a bit of functionality that I don’t think our domain experts need, or want.  The design above allows some very interesting and very wrong scenarios:

[Test]
public void Not_supported_situations()
{
    // Removing orders?
    var customer1 = new Customer();
    var order1 = new Order(customer1);

    customer1.Orders.Remove(order1);

    // Clearing orders?
    var customer2 = new Customer();
    var order2 = new Order(customer1);

    customer2.Orders.Clear();

    // Duplicate orders?
    var customer3 = new Customer();
    var customer4 = new Customer();
    var order3 = new Order(customer3);

    customer4.Orders.Add(order3);
}

With the API I just created, I allow a number of rather bizarre scenarios, most of which make absolutely no sense to the domain experts:

• Clearing orders
• Removing orders
• Adding an order from one customer to another
• Inserting orders
• Re-arranging orders
• Adding an order without the Order’s Customer property being correct

This is where we have to be a little more judicious in the API we expose for our system.  All of these scenarios are possible in the API we created, but now we have some confusion on whether we should support these scenarios or not.  If I’m working in a similar area of the system, and I see that I can do a Customer.Orders.Remove operation, it’s not immediately clear that this is a scenario not actually coded for.  Worse, I don’t have the ability to correctly handle these situations if the collection is exposed directly.

Suppose I want to clear a Customer’s Orders.  It logically follows that each Order’s Customer property would be null at that point.  But I can’t hook in easily to the List<T> methods to handle these operations.  Instead of exposing the collection directly, I will expose only those operations which I support through my domain.

Moving towards intention-revealing interfaces

Let’s fix the Customer object first.  It exposes a List<T> directly, and allows wholesale replacement of that collection.  This is the complete antithesis of intention-revealing interfaces.  I will now only expose the sequence of Orders on Customer:

public class Customer
{
    private readonly IList<Order> _orders = new List<Order>();

    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Province { get; set; }
    public IEnumerable<Order> Orders { get { return _orders; } }

    public string GetFullName()
    {
        return LastName + ", " + FirstName;
    }
}

This interface explicitly tells users of Customer two things:

• Orders are readonly, and cannot be modified through this aggregate
• Adding orders are done somewhere else

I now have the issue of the Order constructor needing to add itself to the Customer’s Order collection.  I want to do this:

public class Order
{
    public Order(Customer customer)
    {
        Customer = customer;
        customer.AddOrder(this);
    }

Instead of exposing the Orders collection directly, I work through a specific method to add an order.  But, I don’t want that AddOrder available everywhere, I want to only support the enforcement of the Order-Customer relationship through this explicitly defined interface.  I’ll do this by exposing an AddOrder method, but exposing it as internal:

public class Customer
{
    private readonly IList<Order> _orders = new List<Order>();

    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Province { get; set; }
    public IEnumerable<Order> Orders { get { return _orders; } }

    internal void AddOrder(Order order)
    {
        _orders.Add(order);
    }

There are many different ways I could enforce this relationship, from exposing an AddOrder method publicly on Customer or through the approach above.  But either way, I’m moving towards an intention-revealing interface, and only exposing the operations I intend to support through my application.  Additionally, I’m ensuring that all invariants of my aggregates are satisfied at the completion of the Create Order operation.  When I create an Order, the domain model takes care of the relationship between Customer and Order without any additional manipulation.

If I publicly expose a collection class, I’m opening the doors for confusion and future bugs as I’ve now allowed my system to tinker with the implementation details of the relationship.  It’s my belief that the API of my domain model should explicitly support the operations needed to fulfill the needs of the application and interaction of the UI, but nothing more.

Leadership is a mysterious art. Whether you're leading an agile development team or not, some of the important qualities of an inspirational leader are obviously the same.

My latest blog post on the subject is now live on Jurgen Appelo's new site, "Management 3.0". Take a look by clicking on the link below!

How To Be An Agile Leader

Kelly.

Photo by BrianForbes37

Dear Mr Bowley,

Thank you for your email regarding the NPfIT. I certainly agree with your point that drawing up contracts for IT systems that have yet to be developed has proved costly for the taxpayer and for Government. Nowhere is this more true than the National Programme for IT where only one hospital has received a full implementation of Lorenzo due to the fact that it had not yet been designed when the Department of Health let the contract with CSC, and only 12 hospitals have received Cerner Millennium – a U.S. system that has had to be adapted extensively for application in NHS Trusts by BT.

Whilst I have not come across the Agile approach before, I will certainly bear it in mind as we seek to develop our policy of giving local NHS Trusts a choice of IT system through a central catalogue of open standards/accredited systems. I will keep on record any further information you are able to provide in writing about the Agile methodology and would welcome any such information in response to this email. Once again, thank you for getting in touch.

Yours sincerely,

Stephen O’Brien

Shadow Health Minister

Pickle adds many convenient Cucumber steps for generating models. Also learn about table diffs in this episode. Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid – all rolled into one format. Pickle gives [...]

The Maven team has gone to the ends of the earth to ensure backward compatibility, improve usability, increase performance, allow safe embedding, and pave the way for implement many highly demanded features. This talk will briefly cover the process and tooling changes that have occurred in the Maven project in order to accomplish what we [...]

Tamara Sulaiman presents experiences in implementing Agile in teams across different time zones in large companies. She shares the pleasure and the pain, ideas that worked as well as ideas that didn’t. She also shares the critical success factors in making program level implementations successful and sustaining. http://www.infoq.com/presentations/distributed-team-tips

I was skimming twitter this morning when I saw a link to an article/blog post in HS site about how they plan to "revolutionize" the way people interact/work with HS today.

First let me get this out of my chest: whoever was tasked with creating this project is either a complete noob in this thing we call the internet or their task was to create a good video for a concept that has no chance in hell to succeed! What a large #FAIL!

Now for the actual content. HS misses the whole internet thing completely.

1. First, they created this video which is about creating a platform that transfers their "paper" product to your screen. Really? Don't you have a little bit of imagination? Or at least look around to see what is happening! People don't want the "old" media in a new format. They want and need a new media, that is a more integral part of their life, not another format to learn!
   


2. Second, they completely ignore that in the age of the internet when the competition is just a click away the media business model has to be about producing good content first and only later about the medium to deliver it. The medium will evolve forever! (remeber sites from 1999? not so successful if launched today!) Having a concept that revolves around the way that media is organized *on the screen* is like trying to build a car by 1800's standards: you know with a 1000 bhp engine on a model T. Totally clueless if you ask me
   


3. Third, the video seems to show that they want to use all kinds of media formats in their content: videos, more photos, more ads, etc. Well, I don't see how a decreasing revenue ecosystem (print media) can really work with a future model that will exponentially increase their production costs (more video report teams, more photographers and photo editors, more expensive content handling and management systems, etc.) I mean, look at Huffingtonpost.com. They are competing for attention with the big guys with a much smaller work-force!
   


4. Fourth (and last - although I could continue for ever), they completely forget that in the age of the Internet, access to content is the commodity, what they should be focusing on is either a content-niche (opinion, creating social dialogue, etc. -- where they have no competition) or then try to create a dialogue with their customers that cannot be replicated elsewhere (like user engagement through social media, etc.). Trying to just create another "way" to access their content, which is closed, limited and will be out-dated 6 months after they spend millions implementing it is not just dumb, it should be considered neglect by WSOY board!
   

Helsingin Sanomat: please wise up and truly innovate! Look around, there's lots of people in Finland with great ideas. Take a risk, listen to them. After all Finland is one of the most advanced countries in online/mobile services. Surely we must have people in this country who can give you great ideas!

Here's the sad, sad video. Well produced, but with the wrong content...




Photo credit: fireflythegreat @ flickr

Recently I've had some time to spare, so I decided to refactor my Backlog Manager into a new version.

Here it is: Backlog Manager v10.1

It is more robust than the previous versions, and has better support for Release Planning.

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Measuring code quality with Sonar
By Allard Buijze, 26 February 2010

“At JTeam, we continuously strive for good quality code. The reason is very simple: bad quality code slows down the development process. The small investment pays out in even the simplest of projects.”

Sonar: a valuable tool for every Java shop
By Hans Westerbeek, 22 February 2010

“If your organization develops Java applications, chances are that Sonar could be very valuable for you. Sonar helps you calculate your technical debt by analyzing your project’s source code.”

Getting More Agile – 2009 in Review
By Thomas Ferris Nicolaisen, 21 February 2010

“With our mavenization efforts, we were recently able to make use of Sonar (which rocks, btw) instead of the old, more primitive (boring) Ant reports in Hudson.”

A Sonar Cobol Plugin
By SonarSource, 18 February 2010

Coming soon… “SonarSource has developed its own Cobol parser and packaged it in a Sonar Cobol analyzer. It allows to perform objective and automated Cobol code quality and standards reviews against pre-defined rule sets and coding best practices. It also generates standard code metrics like number of lines or density of comments”

Add code quality metrics to your GateIn Dashboard with Sonar
By Jeremi Joslin, 11 February 2010

“Sonar is an open source platform to manage code quality. It enables to collect, analyze and report metrics on source code. At eXo Platform, we use Sonar to manage and monitor the quality of our codebase.”

Sonar Integration for AnthillPro
By Eric Minick, 10 February 2010

“A Sonar plugin for AnthillPro is now available through Urbancode’s Supportal (support portal).”

Sonar SCM Activity Plugin version 0.1
By Evgeny Mandrikov, 27 January 2010

“People, who follow me on Twitter, already know about new plugin for Sonar developed by me. Meet – Sonar SCM Activity Plugin.”

Java Build Server
By Manuel Küblböck, 23 Januray 2010

“In my last Java project, I set up a build server with Continuous Integration (CI) capability. I am a big fan of Test Driven Development (TDD) and I quite enjoyed Hudson telling us right away when someone checked in code that broke the build. It just gives you so much more confidence in your code and keeps it releasable at all times. In addition, we used Sonar to measure the quality of our code.”

By Kevin Meyer

Over the past several weeks we've penned many posts about manufacturers that have woken up to the hidden costs of offshore manufacturing or outsourcing and have decided to return to America.  By focusing on improving internal efficiencies and recognizing the extra tangible and intangible costs of global supply chains, cash floating on the high seas, communication problems, and long problem recognition and resolution chains they realize they can offset the supposedly "lower cost" of China and elsewhere.  But just when we begin to get a warmer feeling in our heart we get jolted back to the reality that many, if not most, manufacturers just don't get it. 

The latest Manufacturing News has today's jolt of dolt.

If you can't beat China and can't get the U.S. government to understand what you're up against, then you may as well join them. That is what Evergreen Solar has decided to do, shifting production of solar fabrication and assembly from its factory in Devens, Mass., to Wuhan, China. Evergreen Solar CEO Rick Feldt went to Washington, D.C., and met with Energy Secretary Steven Chu and Commerce Secretary Gary Locke. He told them Chinese government policies made U.S. production uncompetitive.

Without an adequate response from the U.S. government to counter competitive forces working against domestic production, "we are going to China as quickly as we can," Feldt told the analysts. "The issue for us is just how long does it take to get there. We've got the China operations underway as we speak." The company expects to spend $50 million this year on its Wuhan, China, facility.

Better call the waaahmulance...  waah waah...

Evergreen Solar's Massachusetts plant is producing panels at $2.05 per watt, down from $2.24 per watt in the third quarter of 2009. But the 100-megawatt Chinese facility will produce panels for $1.25 per watt, going down to $1.00 per watt by the end of 2012.

Yes a tough challenge.  But look at what they've already done.

The company expects to produce 20 to 25 megawatts of solar cells per quarter in China by early 2011. During that time, the company expects to reduce costs at its Devens [Massachusetts USA] facility to about $1.50 per watt "as we transition panel assembly to China," said Feldt.

Not too shabby, although still quite a ways to go.  But what do these guys decide to do?

In response to the Chinese competitive challenge, Evergreen Solar has two options. It can try to counter China's advantage by reducing its costs in Massachusetts as low as possible, or "get to China as fast as we can," said El-Hillow. "We've tossed internally about becoming more aggressive in Washington, trying to get them to understand the situation that we face as a solar manufacturer and leveraging our wafer technology. There's no silver bullet here. It's an incredibly tough situation." Added CEO Feldt: "The issue for us is just how long does it take to get [to China]."

Waaah.... unbelievable.  The magical government solution.  Of course they've tasted the milk already.

In 2007, the company received $23 million in grants from the State of Massachusetts to build its facility on state-owned property in Devens. It also received $17.5 million in low-interest loans along with a 30-year lease on the property.

And then they found a new use for those taxpayer funds.

Evergreen spent $8.5 million in its fourth quarter on the transition of panel assembly operations from Devens, Mass., to China.

I wonder if those taxpayers realize what their investment is doing. 

I also wonder where they'd be if they put half as much time working on internal improvements instead of whining and lobbying our representatives.  And they should wonder why their high tech operation isn't as efficient as the likes of American Apparel, who beats the socks off (literally) of overseas sweatshops while paying 4,000+ people above minimum wage plus health benefits in the low cost nation of Los Angeles.  One of my favorite examples of a company that simply focuses internally, which happens to have just been called a small cap long-term winner by Motley Fool.

Waaaah... waaaah...

Hey Dov, wanna run a solar panel operation?