Besides the cultural bias (in Italy, one pizza will usually feed one person but it might be different in the USA…), you could use these questions for every project that you are currently running or plan to run.

Reference: “Succeeding with Agile”, Mike Cohn, Addison-Wesley, 262 pages, IBSN 978-0-321-57936-2

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

* Mobile Application Stores, September 7 2010, Zurich, Switerland

* iqnite 2010 Schweiz, September 21 2010, Zurich, Switzerland

* Lean & Kanban 2010 Europe, September 23-24 2010, Antwerp, Belgium

* Software Testing Analysis & Review Conference, September 26—October 1 2010, San Diego, USA

* iPhone/iPad DevCon, September 27-29 2010, San Diego, USA

* iqnite Nordic, September 29-30 2010, Stockholm, Sweden

* iqnite United Kingdom, October 4 2010, London, UK

* Agile Eastern Europe, October 8-9, Kyiv, Ukraine

Find more software development conferences

If you are the committer of an open source project or the marketing manager of a commercial tool, do not hesitate to add your tool. It is free and you will be able to post press releases to communicate about new versions.

Blog: Patterns and Practices for Improving Personal Productivity, Time Management, and Effectiveness

Blog: Earned Value v. Earned Schedule

Blog: A List of Coding Standard Websites

Blog: TDD at the System Scale

Site: Real QA Manifesto

Humour: My husband is a programmer; I have no idea what that means.

Article: jQuery Test-Driven Development

Article: Are We Headed to Abilene?

Tool: Flerry is a Flex-Java bridge for Adobe AIR 2.0

Tool: Coverlipse is an Eclipse plugin that visualizes the code coverage of JUnit Tests

Video: Managing Ruby Teams

Video: How to Cope with Communication Problems in an Agile Project?

Video: Continuous Integration, Pipelines and Deployment

Find more interesting links on the software development links directory, the software development tools directory, the software development articles directory, the software development blogs aggregator or the software development videos directory.

Read the complete review on Sofware Development Books

Reference: “Reflections on Management – How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself”, Watts S. Humphrey and William R. Thomas Addison-Wesley, 260 pages, IBSN 978-0-321-71153-3

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

Sessions may be either tutorial-based, presentations of case studies, or take the form of interactive workshops. We are always open to novel formats, so please contact us with your idea. The standard length of a session is 90 minutes, with some exceptions. In order to allow less experienced speakers to speak at the conference without the pressure of filling a full 90 minutes, we reserve a number of shorter 45 minute sessions.

http://accu.org/index.php/conferences

The Smalltalk business will remain independent and their new web site is http://st.instantiations.com/. Mike Taylor will continue as President and CEO of the new Smalltalk-focused Instantiations. Founder Eric Clayberg will join Google, but will also continue as a Director/Board Member, technical advisor and major shareholder of Instantiations. John O’Keefe will assume an even stronger role guiding the technical development and advancement of VAST.

This acquisition is however not mentioned neither in Google Official Blog or Google Press Releases . On an Instantiations forum posting titled “Seamless migration to Google” , a customer complains that “Unless I’ve missed something the website is no longer available and the support emails just bounce back ? What am I doing wrong ?” It seems that the communication was lacking not only to the external world but also towards Instantiations customers. Mail to my instantiations.com contact is effectively bouncing…

I can understand that this acquisition may be a minor action in Google exciting life. For instance the press release section of Google doesn’t mention also that will stop deploying the Google Wave technology. This is what you call an “update” in PR language ;o)

* Agile 2010 Conference, August 9-13 2010, Orlando, USA

* iqnite 2010 Schweiz, September 21 2010, Zurich, Switzerland

* Software Testing Analysis & Review Conference, September 26—October 1 2010, San Diego, USA

* iPhone/iPad DevCon, September 27-29 2010, San Diego, USA

* iqnite Nordic, September 29-30 2010, Stockholm, Sweden

Find more software development conferences on SoftDevConferences.com

Blog: Why I Don’t Like Pair Programming (and Why I Left Pivotal)

Blog: MSTest vs. NUnit with Visual Studio 2010 & TDD

Blog: Relational Data, Document Databases and Schema Design

Blog: Achieving Agility: Means to an End, or End in Itself

Blog: Lessons learned in building a Model Driven Software Factory

Humor: JavaZone 2010 Promotion Movie

Web Site: HTML5 Rocks

Find more interesting links on the software development links directory, the software development tools directory, the software development articles directory, the software development blogs aggregator or the software development videos directory.

http://jz10.java.no/java-4-ever-trailer.html

Thus came the question: do software developers make more difference than accountants for their CEOs? Are they just something you need to have, but don’t really contribute to the performance of the organization? Off course, some of you could work for the Faceboogle-type of companies where software IS the product (or a big part of it). Some of you may also work in Enron-type of companies where accountants make a big difference ;o) In many other companies, software is an important support and enhancer of the activity: managing supply chains, customer relationships or monitoring mechanical products like car engines. However, the software development function is separated from the other operational activities. Developers are considered as a support function as accounting could be. This comparison is not so awkward, as accountants belong also mostly to the introverted psychological category, like developers. And accountants could also deliver information that could change the way a company works, finding for instance which products or customers are truly profitable.

In a book from Watts Humphrey, he quotes Dick Garwin, the designer of the hydrogen bomb, saying: “You can get credit for something or get it done, but not both.” Software developers may belong more to the second part of this alternative. Despite all problems that impact our projects, we deliver solutions that allows organizations do perform better, but we don’t get all the recognition that we deserve. Some might be happy with our current lack of visibility, but then we should not complain if we are often considered only as a cost variable that should be minimized and not elements that could increase revenues. To achieve this objective, it is important that developers get closer to their users and improve their knowledge of business. Users don’t want a cool Ruby on Rails Ajax apps, they want solutions for their problems. If we want more consideration from the high management, we might have to express more our positive impact in organizations. After all, even some accountants managed to do this.

80 pages of software development knowledge that you can download from http://www.methodsandtools.com/mt/download.php?summer10

Web Site: NoSQL Databases Portal

Humor: Geeks and Nerds

Blog: Confessions of a programmer: I hate code review

Blog: Architecture Review: Mock-Driven Three-Layer Architecture

Blog: Builds Are Complex So Choose Your Tools Wisely

Article: Evolutionary architecture and emergent design: Using DSLs

Article: Effective Retrospectives & Reviews

Tool: Gerrit Web based code review and project management for Git based projects

Tool: Instinct is a Behavior Driven Development (BDD) framework for Java

Video: Non-Functional Requirements: Do User Stories Really Help?

Video: How Mozilla uses Selenium

Video: Guiding Your Personal Life: Plan-Driven or Agile

Find more interesting links on the software development links directory, the software development tools directory, the software development articles directory, the software development blogs aggregator or the software development videos directory.

The book starts with a presentation of Agile and Lean principles. The second part explains how Lean adoption can improve the usage of Scrum with an interesting table comparing Scrum and Lean accompanied by a list of practices to avoid. It devotes specific chapters to topics like release planning, visual control, quality assurance, product coordination and architecture. A final part is dedicated to more insight in the Lean approach. The book is pleasant to read. Each chapter has an abstract and the beginning and a summary at the end with some questions and further reading recommendations.

Besides the sometimes-annoying references to the authors consulting firm, this book provides interesting material on specific aspects of Agile software development projects at an enterprise level. Its main difference with other books on the same topic is for me the treatment of the management aspects of software development as the authors make their point for a stronger management role and intervention in Agile projects. This book will therefore bring more benefits to project and development managers that work for large organizations where the control aspect is important and the words “self-organizing teams” could be a serious “career limitation” move.

Reference

“Lean-Agile Software Development”, Alan Shalloway, Guy Beaver and James R. Trott, Addison-Wesley, 262 pages, IBSN 978-0-321-53289-3

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

Quotes

“What we need is a new attitude about process and how to manage process. Processes must be designed to assist the team in achieving management’s goal. Processes help the team get its job done: they represent accountability among team members about how they will work. [...] Is this possible? Yes! Lean provides the principles we need to do this. And we will not follow these principles blindly.”

“We often think of software as the end goal. But it is not. Software is a means to an end – a way of getting value to the customer.”

“Agile project management done in isolation violates the Lean principle of optimizing the whole. [...] There are other alternatives to Scrum, including Crystal, Feature-Driven Development and Kanban software development. They are good and they address specific challenges for teams. However, they, like Scrum, do not entirely address the bigger picture. By themselves, they do not address the entire value stream, which is what is needed.”

“While Scrum works well at the team level, using it as the primary method to guide Agility at the enterprise level has severe challenges.”

“Ken Schwaber and Mike Beedle define the Daily Meeting as composed only of team members, explicitly removing management from it – and subtly implying management is not accountable for deliverables.”

“Scrum works by exposing inadequacies or dysfunctions within an organization’s product and development practices. [...] The Scrum community generally concedes that about three in four of organizations implementing Scrum will not succeed in getting the benefits from it that they hoped for. The explanation is that many organizations change Scrum in order to accommodate the inadequacies or dysfunctions of the organization rather than solving their organizational problems. The implication is that Scrum gives them the tools to see but not to change.”

It is difficult for me to summarize all the ideas that were discussed, but here are some nice quotes excerpted from this presentation (I hope to be precise, but all misunderstanding are my own responsibility):
* As a profession software development do a mess of words
* If you are using java.util.date, you must be tired of life
* Typing is not the bottleneck in software development
* Every time a mock returns a mock, a fairy dies
* Don’t confuse the ideas of the programming language with the essence of what you are trying to express.

Matthew McCullough made a very interesting presentation of the improvements that will be available with Maven 3, currently in its final beta testing period. The new version will be faster and have a smaller footprint, due to a codebase reduced by 30%. The software has been transformed in a code library that allows a better integration with third party tools. An important improvement is the possibility to define your configuration in different languages (ruby, groovy, scala, clojure) with polyglot maven. He also presented the last version of m2eclipse that he likes for its ability to visualize dependencies and to provide tools for an easier refactoring.

Slides of all the presentations of Jazoon are now available on the conference web site . Videos will be published late on the excellent Parleys web site.

He discussed the current evolution of Java towards its version 7. There has been a lot of work on the modularity side, removing as much as possible the dependencies between the Java modules. Parallelism has also been improved and will now for instance be used by most of the garbage collector activity. More than 100 languages are now running on the JVM. The Da Vinci project goal is to improve the efficiency of other languages on the JVM. Finally, some small additions are made to the syntax to simplify the language. JavaFX release 1.3 was also announced in May, the fourth release in the last 18 months. Performance has been improved and new UI components have been added. For those who want to see it in action, Danny pointed us towards the web site of the last Vancouver Winter Olympics, more precisely the geographical view of medals.

The next two sessions that I attended were both about Java and Flex. In the first presentation, Adobe Evangelist James Ward did first a small introduction to the Flex technology. Then he showed us how it was easy to connect a Flex front end with a Java back end using different protocols (http, web services) and benchmarked their relative speed. All his demos are available on http://www.jamesward.com/demos/. You can check the insurance one for a small taste of what a nice Flex interface can look like.

The second presenter, Florian Müller, put a different perspective on the marriage between these two technologies with his experience on a large project that was involving both of them. The development of the application can be very easy, but the maintenance is more difficult as functions can be performed either at the client (flex) or server (level). Architecture rules have to be defined very well and synchronization between the server and the client is not easy to maintain. Flex 4 solves part of these problems, but the proposed life cycle (Photoshop – Catalyst – Flex) does not work well when you have go backwards and redo some things. In the tools that you can use to link Java and Flex, he recommends Granite Data Services as an open source application that provides good power.

Read this report here

Nothing beats experience in software development and usually you learn the important things the hard way.  This presentation is based on an O’Reilly book with contribution from 73 different people and edited by Kevlin Henney. He presented for us 17 of them in his lively style.

1) Do a lot of deliberate practices
Kevlin added: “to make the task, not to complete the task”. He compared this with a cello player that will exercise for hours just to perform rarely on stage. The importance is not to realise things but to be confident when and how to use coding techniques.

2) Learn to estimate
This part deals with the difference between estimate, target and commitment. It is contributed by Giovanni Asproni, a Methods & Tools author. For a more detailed discussion, look at his article  “Fingers in the air: a Gentle Introduction to Software Estimation”

3) Know your next commit
It is a good thing to have a big picture of your current project, as in “I am working on this user story for my customer”, but developers should also be able to focus on the current task, as in “I am refactoring the CreateAccount code”.

4) Comment only what the code cannot say
If a program is incorrect, documentation matters little.

5) Code in the language of the domain
Use in your code names meaningful for domain, like AccountNumber or CreateAccount for a bank.

6) Prefer domain specific types to primitive types
DistanceInMeters is more meaningful than integer

7) Resist the temptation of the singleton pattern
You are never sure that there will always be only one instance of an object.

8) Don’t repeat yourself
Duplication is waste. Repetition in process calls for automation. Repetition in logic calls for abstraction.

9) Beware of the share
On contrast with the previous item, sharing code libraries creates dependencies for code that could evolve separately and that are just temporally coinciding.

10) The road to performance is littered with dirty code bones
Sometimes you just get better performance with less and cleaner code

11) The longevity of interim solutions
Try to avoid them… or take time to clean them after implementation.

12) The Boy Scout rule
You should leave the world just a little better than you find it and improve in little increments.

13) Two wrongs can make a right and are difficult to fix
Sometimes a bug is “corrected” by another bug further in the code. When you try to fix the second, the first one is revealed, but difficult to detect. It could be easier to leave things as they are.

14) Read code
We love to write code, but when it comes to reading it, we usually shy away. Reading code help us improve our writing abilities and increase our knowledge of programming styles.

15) Write test for people
Your tests are targeted at the person that is trying to understand your code. Tests are here to document the code and tell what it means to be right for the code.

16) Don’t be cute with your test data
because somebody else could see it ;o)

17) Ubuntu coding for your friends
This is not a reference to the Linux version, but means rather than your code might be used by your friends. If your code is bad, then their code will be bad.

The full list of 97 things is available on http://tr.im/97tepsk

“I’ve personally witnessed several failed agile adoptions that could have been prevented. The first was in a company that had spent more than a million dollars on its transition effort. Executives brought in outside trainers and coaches and hired five people into an “Agile Office” to which new Scrum teams could turn for advice. The company’s failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization. The executives who initiated this transition thought that educating and supporting developers would be sufficient. They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department. Without changes to these areas, organizational gravity pulled the company back where it had started.”

“Perhaps you’ve read a book, on Extreme Programming and have decided that is the right approach for your company. Or maybe you attended a Certified ScrumMaster training course and think Scrum sounds good. Or maybe you read a book on a different agile process, and it sounds perfect for your organization.
In all likelihood, you’re wrong.
None of these processes as described by their originators is perfect for your organization. Any may be a good starting point, but you will need to tailor the process to more precisely fit the unique circumstances of your organization, individuals, and industry.”

“With most organizational change, after someone figures out the right or best way to do something, that way of doing it is captured as a ” best practice” and shared with everyone else. For some types of work, collecting and reusing best practices is a tremendous aid to the change effort. An organization that is selling a product to a new type of customer may, for example, capture best practices for overcoming objections from potential customers. When transitioning to Scrum, however, collecting best practices can be dangerous.”

What is interesting for me in these quotes is the emphasis on Agile being a process and not a technique. You can’t just apply existing recipes to your organization and think that you are “done”. You have to think on how you can spread the spirit of Agile in your organization and, when you think you are “done”, continue to try to improve your process every day. The same message is conveyed in a Karl Scotland article about Kanban that I am just reviewing and that will be included in the Summer 2010 issue of Methods & Tools. Another very interesting article by Yves Yves Hanoulle on Core Protocols will give you tools to support the improvement process.

Reference: “Succeeding With Agile”, Mike Cohn, Addison-Wesley, 463 pages, IBSN 978-0-321-57936-3

Methods & Tools articles on Agile adoption

Adopting an Agile Method

Agile Delivery at British Telecom

Creating an Agile Environment

Agile Coaching Tips

Five Symptoms of Mechanical Agile

* Jazoon, June 1-3 2010, Zurich, Switzerland

* Better Software Conference, June 6-11 2010, Las Vegas, USA

* Agile Development Practices West Conference, June 6-11 2010, Las Vegas, USA

* Domain Driven Design (DDD) exchange, June 11 2010, London, UK

* iqnite Geneva, June 15 2010, Geneva, Switzerland

* Flex on Java eXchange, June 18 2010, London, UK

* ShareConf, June 22-24 2010, Munich, Germany

Find more software development conferences on SoftDevConferences.com