in

Ative at Work

Agile software development

Ative at Work

JAOO 2007 - Uncle Bob, Agile on the Mainframe, Jazz and Intentional Software

Robert C. Martin did the opening keynote with the title “Clean Code II – Craftsmanship and Ethics”.

As always Uncle Bob is an inspiring speaker and the keynote was a good kick start of the conference – why we are here. Some of his well-known issues to focus on and improve:
  • Discipline
  • Short iterations
  • Don’t wait for definition: The customer doesn’t know what they want anyway. The team should participate in the definition of requirements.
  • Abstract away volatility:  Don’t place code together that change changes for different reasons. Eg. don’t mix GUI with business logic.
  • Commitment > Omitment: Help find a solution to the problems instead of just blaming someone else.
  • Decouple from others: Build stubs and simulators for your external dependencies.
  • Never be blocked: This is the prime directive. If you can’t get a QA environment when you need it, use a dev machine.
  • Avoid turgid viscous architechture: There is no single perfect architecture. Ivory tower architects are useless - architects must write code.
  • Incremental improvement: If you have bad code, improve you code incrementally. Every time you work on a part of code you should improve the quality, gradually improving the entire system.
  • No grand redesign: Related to the above point. Grand redesigns always fail. And where are the requirements for the redesign? In the current system, which will be a moving target and the redesign will never catch up.
  • Don’t write bad code. The only way to go fast is to go well. As a development team our product is code. If the code is a mess the product is a mess. Focus on code quality, you can change the development team, management or the process – but bad code stays.
  • Clean code: clean code is code with no surprises.  Make small functions (20 lines).
  • TDD
  • QA should find nothing:  Probably they will, but this should be the mindset.
  • 100% code coverage
  • Avoid debugging
  • Manual test scripts are immoral
  • Definition of done: Don’t have more than one definition of done, done counts.
  • Test through the right interface
  • Apprenticeships
  • Use good toolsConclusion: as always – he is so right. 
 Experiences with Agility in the Mainframe Environment
Dr. Jan Mütter, LSD NRW.

Dr. Jan Mütter from a German government mainframe project, told about his experiences with agile methods . The first year they worked the “traditional way”: the customer (the government) sending specifications to the development team. The team checked the specification. If it had errors or the team was responsible for any issues in it, the specification was send back to the customer.After one year and almost no progress, they decided to change the process:
  • Customer co-location, the whole team in one building.
    Findings: Remarkable improvement in team communication. Extensive rework on nearly all results (code and documents).
  • Planning game, weekly status meetings and adjustments. Detailed tracking of work packages.
    Findings: low leadtime from requirement to implementation.
  • Weekly build and deployment.
    Findings: problems with configuration and release management.
  • Weekly test, full automation on all tests.
    Findings: Lot of rework because of requirement changes. Test scripting very costly.
  • Release and configuration management.
    Findings: necessary but very costly.
  • Refactoring
  • Change Request management
    Findings: Lot of rework. No differentiation between work package, change and defect. Large positive effect on culture and discipline.
  • Project organization and communication. Software design team makes FQA in relation to requirement analysis.
  • Pair programming. The developers were encouraged but not forced to pair program.
    Finding: Low acceptance.
  • Common goal for the team and the customer (working together).
They used VisualAge as development tool on the mainframe and the build in ITF test tool. This combined with the fact that they didn’t have a lot of “old” mainframe developers made it possible to make weekly builds and automated tests.

The conclusion: The environment (goverment company and goverment customer) were a big challenge. E.g. the “service” organization (system operation) did not have the same goal as the team, it took one year to install and configure WebSpherer on the maninframe.The transition gave the project a major improvement, but are still a lot of things to improve.

Developing Software like a band plays Jazz - From Eclipse to Jazz"
Erich Gamma, IBM.

Erich Gamma is a Distinguished Engineer at IBM Rational Software's Zurich lab. He is one of the leaders of the Jazz project. He was the original lead of the Eclipse Java development environment and is on the Project Management Committee for the Eclipse project.Erich gave a introduction to “jazz” and used the Eclipse project at reference (“the eclipse way”).The Eclipse way (in short):
  • 6 week iterations.
  • Milestones first (time boxed). Make milestone results visible.
  • End game: Tight schedule. Process rules have high priority, bug rate and velocity rates go down.
  • Team first. Focus on the team. Small teams. Different time zones (8 locations). Each team have their own plan. Many roles in the team -> every one can “step in”.
The Jazz product gave the team a lot of information about the project (current status etc.) and can ease many tasks. E.g. it can auto generate a server environment as a copy of the last build (very usefull if/when the build fails).

Conclusion: Jazz has some interesting features, but it is targeting big organizations (like IBM) or control freaks. If you use the full feature set, it will not necessarily give you a more agile project team. A more lightweight product and process might give you a better result. 

"Intentional Software - Democratizing Software Creation".
Charles Simonyi, Intentional Software Corporation. Henk Kolk, VP and CTO, Capgemini

Charles gave an introduction to how they try to accelerate innovation by integrating the business domain experts into the software production process. They used a case from Capgemini (Netherlands) where they used the Intentional Software tools to create pension systems.

Their approach is to ask the business domain experts how they describe a new pension product. In this case they use a large Excel spreadsheet to describe the business rules. Capgemini made a customized view/ editor to the customer that looked like the spreadsheet they know.

Before this the customer used 5 very skilled developers and 3 years to create a new pension product. With this new approach (combined with the Intentional Software tools) it took one person 3 months to create a new pension product. They also converted apox. 40 products within 6 months.

Charles used a CAD application as semaphore: the designer draw a circle, it can be a cylinder or a ball. If you change the view you can see how the object looks. The designer doesn’t care about how it is stored in the database. The base system (the CAD system) can be used in many different types of design projects, it is not customized for one specific customer or project. It holds common information’s and properties for “objects” regardless of their usage.

Conclusion: This session showed a red line from the 1970’s where Charles created the first WYSIWYG editor, his time from Microsoft where he was the father of Excel and Word.

The session opened our eyes for a “new world” of software development. The question is when will it be available to the general market, and not just selected partners?

Published sep 30 2007, 02:53 by Kim Horn
Filed under: , ,

Comments

 

battery said:

We have an enhancement request for that functionality - I’ll append your comments to that request.

juni 20, 2008 12:03
© Ative Consulting ApS