I’ve been lucky enough to have been using Spring for just over 4 years. If you don’t know what Spring is, it solves a lot of problems in complex Enterprise Java Systems. And it makes those systems more configurable; Spring makes your code like Lego blocks. Blocks that you can take apart and use again and again (no matter what the underlying technology is). And because you can take it apart, it makes your code easier to test. And testing is a good thing - the earlier you find bugs , the cheaper they are to fix.
Get the feeling that I’m a bit of a Spring fanatic? Wasn’t always that way. It took me two projects where other people had choosen Spring to convince me. And did I mention that it’s one of the most in demand skills in the Java world?
Rod Johnson (aka ‘Mr Spring’) is speaking in Dublin at the Westin hotel Dublin on the 11st March. It’s fairly central, and it’s a breakfast briefing, so you don’t even to have to arrange the day off work. More details on the event are on the Kainos Website.
Update: The registration form to sign up for the event is here.
In an ideal world, potential customers would read this blog then decide that they want to do business with me.
In the real world many of my customers haven’t heard of a blog, and are quite happy that way thank you very much.
Given that a lot of ’selling’ to these customers is on a personal level, the fallback is to use the traditional common or garden CV. Which gives rise to the following problems :
- Too Long or Too Short? : How do you get 13 years experience into a document without it looking like a version of ‘war and peace’?
- The curse of the technical buzzword : You need to include the technical buzzwords (Oracle, Java, Agile etc) to show you can do the job (a lot of people just do a 1st scan for words like this). But, put too many in, and you just end up looking silly.
- People or Technical skills: Apparently you can have great technical skills , or great people skills , but not both. How do you stop yourself getting pigeonholed? What about non-traditional experience (e.g. blogging, writting, speaking, training?)
- Customer confidentiality: A lot of the stuff we do is internal to clients. But potential clients need to know what you’ve done to judge your work. Where’s the balance?
You can judge how successful I’ve been here: Paul Browne’s CV online [pdf].
Yes, I’m slightly more available than normal in the coming months. Yes, I’ll consider proposals slightly outside ‘normal’ contracts, if the projects and upside are interesting. And yes , I may just take some time off that I’ve been promising myself (but I’ve said that one before). Email me at PaulB@firstpartners.net.
Note to recruitment agencies: I’m very happy consulting through FirstPartners. No, I don’t want a permanent job. No, Cork is nowhere near Dublin , but I will consider Belfast. No, I don’t believe that you’re in for anything other than the money - that’s ok , you probably have a family to feed; but let’s not waste time pretending otherwise.
I’ve written and presented quite a bit about Agile Project management, but I’ve to recognize that these guys are experts. This PDF is a 90 Page guide to Scrum and XP Project Management, written in a way that both Business and Technical people can understand.
[Link to crisp OO and Java consultants]
It’s clear , it’s honest , and more importantly , it’s not trying to sell you anything (Rational consultants, you know who you are). Ok, they’re not trying to sell you anything , not unless you’re in the market for a bit of OO consultancy in Sweden.
The best thing about doing presentations is the questions you get asked at the end. Apart from the stomach churning moment of ‘will I be able to answer this one?’ they give you a new angle on things that you may have always assumed, but force you to think of in a different way.
Take one of the questions after yesterday’s Enterprise java presentation at DCU. One of the topics mentioned in the final ‘putting it all together’ was the Agile and RUP (or other upfront design) methodologies. The question , coming from an attendee that was keen on using Agile , was ‘How do you do Architecture in an Agile project?’
On the face of it this seems a contradiction. Agile in it’s most extreme form is ‘make up just enough design as you go along’, with automated tests to make sure changing things later is a relatively low cost and pain free process. In real life most projects are a balance between Agile and need some element of a more formal process (often trying to answer the question ‘how mucn is this going to cost?)’
So , how do you merge Agile with an upfront design process? It’s easier than you think.
Most systems built the ‘traditional way’ do not get all their design done in one go. They might start out with the best of intentions for phase 1 with a clean sheet but over the months / years people come and go, business requirements change and different phases try to deliver different things. Over time the original clean design twists and turns and you work hard to try and make it work out ok. Some of features you thought were key may end up getting thrown out as too complicated.
Now Agile architecture is a similar situation. Each weekly / monthly iteration is like phases on the larger project , with twists and turns that may be unexpected. The difference now is that you have a safety net comprised of your (J)Unit tests, to allow you to make radical changes if your blueprint ends up in a cul-de sac.
Yes, it is ok to have an idea the bigger picture and where you like to go with the design. Yes, a good architect will find reasons in the current release to build towards that design. And yes, a good architect may admit that some of the design features he / she thought were required weren’t actually needed. The difference between Agile and Upfront architecture is in when you find your ‘Don’t really need it’ point. With Agile , you find it just before you build it. With upfront design / architecture you find it when it’s already too late.
And the results of the Virtual Java Meetup are … here. Names have been changed to protect the innocent.
If you couldn’t be bothered reading the entire thing , the results of the Dublin Jury on ‘what technologies should I be learning in the next 12 months’ are:
- Web services are going to be big, but only if they can be simple.
- EJB 3 and Netbeans are both worth taking a look at again, they are now much better than the previous versions that gave them a bad name.
- Middleware (e.g. workflow and Rules Engines) are interesting in a corporate environment, but there is a high barrier to entry.
- Struts , and to a lesser extent JSF , will continue to be dominant Java Web frameworks, despite not being the best technical choice.
- A lot of companies are still using Java 1.4, but may make the leap to Java 6 (Mustang).
- Service Orientated Architecuture (SOA) is a nice idea, but not so many projects have been implemented using it.
- IDE’s (Netbeans / Eclipse / JDeveloper) can deliver a lot of value, but only if backed up by lower level tools (e.g. Ant and Maven).
- More for the next 24 months , keep an eye on Apache Service Mix.
It’s pretty ironic , given that I’ve already stood up and did a presentation on the topic to the INDA, but today we have a UCD exam in Agile Project Management.
In perhaps the worlds first use of a blog as an exam revision technique, here are the main features of Agile projects:
- Working Software over Comprehensive documentation
- Customer interaction over Contract negociation
- Responding to change over following a plan
- Individuals and interactions over processes and tools.
In the meantime , if you don’t have an exam this morning , check out the NoUnit Agile tool that we build and maintain.
If you’re very observant , you might notice that this post is about a week late. Still , here are my notes on the slides / nodes from the final day of the Agile course.
Previous Posts from the training course are:
Junit Introduction
-
Junit
Framework for writing automated unit tests (don’t need to use Junit
to write the tests , but it helps)
-
All Junit
tests extend TestCase
-
Individual
test methods (pre Junit 4.0) : public void testSomething() method
signature
-
Use
assertEquals assertTrue assertFalse assertNull assertNotNull
assertSame and fail methods for testing.
-
SetUp() and
tearDown() methods called before and after each test method.
-
TestSuites
(groups of TestCases) replaced by Ant and (Eclipse) IDE
functionality
-
Run tests via
built in Text / Swing test running , or more likely use IDE / Ant
integration.
-
Organise via
same or paralell folders
-
TestMyClass
or MyClassTest
Mock and Stubs
-
Problem: some
classes (Collaborating Objects) can be tightly bound to system
resources (e.g. File or Database) or to a hard to test API. Another
example is the observer pattern. How do we unit test these?
-
Solution: use
fake object , pass it to class under test , allows testing of the
class at a unit level.
-
Stub : fake
object that uses hard-coded data , often following an API. Many
ready made stubs available (e.g. For the JDBC libraries).
-
Replace
expensive to create objects
-
Have to
create all objects that production code interacts with.
-
Start in
middle and develop outwards
-
One failure
can ripple out / appear elsewhere.
-
Crash Test
Dummy: type of stub that deliberately fails in order to test
exception handling – simulate database crash or I/O full.
-
Self Shunt is
where the unit test itself implements the interface (doesn’t work
for classes) and gets callbacks from the class under test.
-
Mock Objects
like stubs, except that they are intelligent enought to self-verify.
-
Mock
Secondary objects (normally ones that we build) instead of API (as
Stub does)
-
Outside in
development style
-
What if mock
implementation is incorrect?
-
Interaction vs. State: In
state-based testing you check the tests by examining the state after
the stimulus. In interaction based testing you check the right
interactions were triggered by the stimulus - Martijn
Fowler, http://martinfowler.com/articles/mocksArentStubs.html
-
Mock objects
tend to test more the interaction between objects rather than a unit
test of the object itself.
-
Stub rather
than mock external API’s
Smells and refactoring.
-
Code smells
are bad or suspect design decisions in code.
-
Not always
bad , but should be looked at (often will involve a trade off)
-
Smells are
often hard to understand , hard to change code.
-
Refactoring :
Small , controlled changes to codebase , so that it continues to
compile / tests run to improve the design. The behaviour remains
exactly the same.
-
Seperate
refactoring and adding additional functionality.
-
Easier with
automated tools and Unit tests to confirm that nothing has broken.
-
Refactoring
!= Rewrite. Codebase is evolved , not thrown away.
User Stories
-
In some ways
, equivalent to Use Case from Predictive methods (but with subtle
differences).
-
Represent
chunk of functionality that makes sense to the customer.
-
Can be
represented as card / conversation / paper based documents (more
predictive approach).
-
In Agile (as
opposed to predictive) , shift the focus from writing to talking
i.e. Get a true understanding of what the customer wants , even if
they haven’t expressed it very well.
-
Lessen the
importance of requirements
-
Support
iterative development and participatory design.
-
Even a simple
requirement has many possible permutations (that lessen the odds of
getting it right.
-
Not just a
generic user – but more user roles – groups of users that do
different things with the system , depending on their experience ,
task at hand etc
-
User Stories
should be Invest:
-
Independent
-
Negotiable
-
Valuable
-
Estimatable
-
Small
-
Testable
-
Templace
(FlashCard , as used by Xplanner)
-
Be careful of
size
-
too big and
cannot be used for estimated (break these down into smaller
stories). Easy for Compound , but for complex stories might need to
do some research and then break out.
-
Too small ,
and it is not worth the admin of estimating each. Bundle them up
into higher level task like UI improvements or bug fixes.
-
User Story
should give us the acceptance tests
Below are my notes from the Agile course so far - covering introduction to Agile projects , why it makes business sense, the use of FIT and other acceptance testing tools what Agile means for customers , managers and teams.
These notes are a good complement to the Agile presentation I gave.
Introduction to Agile
-
Requirements
Change on project – it’s going to happen , clients (paying for the code) have the right to change their mind , accept it and get on with it.
-
Agile Family Includes
-
XP (Extreme Programming)
-
Scrum
-
Adaptive Software
Development
-
Lean Software
development
-
Feature Driven
Development
-
Crystal
-
DSDM
-
Values
wrap Principles wrap Practices
-
Values
(from the Agile manifesto)
-
Individuals and interactions over processes and tools.
-
Working software over comprehensive documentation.
-
Customer collaboration over contract negotiation.
-
Responding to change over following a plan.
-
Principles
(Customer Focused)
-
Deliver early, deliver often.
-
Deliver valuable software.
-
Welcome change.
-
One
Big team (business people and developers)
-
Principles (for Management)
-
motivated individuals give better results
-
face 2 face is the best way to communicate (although accept need to
communicate across location and across time as good 2nd
best).
-
Remember : working software that meets business needs is the primary measure
of progress
-
Promote sustainable development (or you’re just going into Technical Debt)
-
Principles(for Teams)
-
use technical excellence and good design to promote agility but
-
simplicity is essential
-
the best architectures, requirements, and designs emerge from
self-organizing teams (rather than imposed from above)
-
do continual improvements to the process
-
Practices
-
Why Agile
-
Waterfall projects : we’re most likely to find bugs in testing phase at the
end , when (a) we’re most likely to be under time pressure and (b)
when they’re most expensive to fix.
-
Waterfall projects: Hard to know how far through we are , as each step is
different from the last (design has gone well , but will coding do
better or worse?)
-
Agile:Testing is continuous, so likely to get early feedback and
resolution of bugs. Testing = Unit Tests and Acceptance Tests.
-
Agile: Progress is steady and measurable , as we carry out all
tasks as part of a regular cycle.
-
Productity = doing less but producing more value. e.g. Customer can prioritize
highest value tasks and we deliver these first.
-
Standish group stats showing small projects are more successful.
-
Deploy early and often gets usable software into the hands of users sooner
where it can start to payback it’[s investment earlier.
-
Success factors for Agile projects:
-
Still hard work to do:
-
Good people give good software
-
Can be faked , so people really need to buy in
-
Practices are learnable / a lot are common sense
-
Recognize reality
Informative
Workspace
-
Person walking into 'normal' coding office has no idea of what is going on, nor what status it is at. Most of the stuff is in people's heads.
-
Informative workspace seeks to communicate this information (via simple methods)in the office e.g. Notice boards, coder of the week hat , printed graphs of velocity , iterations etc.
-
Kent
Beck : "An interested observer should be able to walk into the team space and get a general idea of how the project is going in 15 seconds. "
-
Similarto Kanban idea – while going for Just in Time / continual improvement , visual representations are displayed to demonstrate
progress.
-
Information Radiators : anything that gives out info (example given of monitor running , showing latest build progress).- jokey examples of Lava
Lamps / notes in toilet
-
Toyota (Toyota production system – recognise their edge is in how they build their cars, and not just the cars that they build).
-
Human face to automation.
-
Board giving current
production status
-
Audible Cues
-
Ability for anybody to stop the line.
Testing and Design by Contract
-
Started by Bertrand Meyer in the Eifel Language
-
Frameworks available to add these (fully) to the Java Language – over and above the functionality available in Java 1.4 (the assert keyword)
-
Already have a contract that is enforced by the compiler in Java (e.g. Method signatures , return types)
-
Adds to this , to be a finer grained level .e.g method should return not only an Integer , but an Integer of value 0 to 100
-
Like every contract both sides (Caller and Callee) have responsibilities
-
Pre Conditions : Condition that must be true when the method is called.
-
PostConditions: Condition that the method guarantees when it returns
-
Class Invariants state what will be true at a class level (once all pre-conditions at method level / constructor level satisified)
-
Both pre and post provide additional specifiication (.ie. It is clearer to people using the code what is required / what it does). As such
provides clearer design and additional documentation.
-
Can make code more succient by replacing 'boilerplate' code with standard check (e.g. Precondition param must not be null).
-
Java
Example :
-
Pre
Condition /** @require !empty() */ - as
javadoc on method (multiple checks allowed) –
-
Post
Condition : /** @ensure !full()*/
-
Class Level invarient: /** @invariant 0 <= count()*/
-
Exceptions
-
Pre Condition violation should give RuntimeException – provide method to test before call (e.g. IsEmpty() before doing remove)
-
Post conditions: supplier should be every effort to fulfill these : so if it can't , it is normally due to an Exception (callee should be prepared for this failure)
-
Junit
-
Codein Junit verifies the contact of the class (and provides documented example of code use)
-
assert methods = post condition testing
-
test invarient by checks at class and not just method level (e.g. Check overall status of class, not just return value of method under
test)
-
Pre conditions by be tested by violating these in setup (code before call to method/ class under test) and ensuring exception is thrown.
-
Think about Test as a contract.
Acceptance Testing
-
Acceptance Tests – defined (or agreed by customer) , states thatfunctionality is complete
-
Differ from unit tests in that they are system wide rather than at class/unit level.
-
Unlike unit tests don’t need to be a 100% all the time (but once passed , should alway pass)
-
Automation is nice (for developer and customer)
-
Sample Frameworks for Automated acceptance testing
-
FIT – see notes below
-
Exactor – see notes below
-
Fitnesse – FIT but wiki based (easier to do multiple tests , easier to communicate these to a team.
-
WinFIT runner
-
Inputto all these tools is close to a spec (close in that typicaluser , after one walkthrough should be able to understand what the documents mean).
-
Tests can be written before application is build (again, the notion of the tests forming a spec). A lot of the commerical tools ,
especialy those that record against a ‘live’application, do not allow this.
-
Automated Acceptance Testing with FIT
-
Allows Customer s to review (if not write) the acceptance tests.
-
Previously would have done these tests manually , or via large Junit tests (i.e. Use Junit not as Unit testing , but a way of describing the entire app from the user point of view).
-
Data (unlike in Exactor) is specified as a HTML table. All non-tables are ignored (so safe to created tests documents using MS Word).
-
Fixture (connects this HTML Data) to run test against 'production' code.Fixtures are written by programmers (as part of proving code meets
the spec). Three types of fixtures.
-
Column
-
One class for each table
-
Fit works through on a line by line basis – good for repeating the same action over and over again.
-
1st Line of Table : Class Name to be tested
-
2nd Line of Table : class variable or methodName() to be set / called
-
3rd –
Xth lines of table: values to set or expected values to be returned
-
Good for testing Domain (Business) Logic parts of an application
-
Action
-
mulitiple class for
each table
-
start – the class to be tested
-
enter – value to be passed into method (no return value)
-
press – call method (no input or output)
-
check – check value on method (no input)
-
Good for stimulating interaction with the user interface (or more accurately either the controller that sits just behind the user interface).
-
Row
-
Like Column , but interprets all at once (rather than one at a time)
-
extend RowFixture ,
provide query[] and getTargetClass() methods – allows Fit to see what data structure
-
good for testing coding in the service / persistence / db layer of code.
Automated
Acceptance Testing with Exactor
-
-
Exactor (http://exactor.sourceforge.net)
-
Allows Customer s to review (if not write) the acceptance tests.
-
Previously would have done these tests manually , or via large Junit tests (i.e. Use Junit not as Unit testing , but a way of describing the entire app from the userpoint of view).
-
Comprises (like fit) of
-
Script – a text file thatyou could show the customer.
-
Commands : what the script calls , extends Exactor classes. These commands then call the code beingtested.
-
Command extends Junit assert –
so usual capabilities available.
-
Command provides access to test wide map to allow storing / exchange of values.
-
Allows composites to reuse scripts.
-
Scripts allow placeholder parameters
Day 3 of the Agile course.
Today’s topic was mock and stub objects, refactoring and automated acceptance tests using Fit and Exactor. Worked through Video Store example (from refactoring) to remove code smells.
Day 2 of the Agile course (provided by Exoftware) at UCD. Most of yesterday (day 1 that I missed), was good , but standard introduction , including:
- Differences between RUP (Rational Unified Process), Extreme Programming (XP) and Agile approaches.
- The XP / Agile Planning Game.
- Problems with the existing software development process.
Today (Day 2) is a lot more ‘hands on’ in that it’s straight into the computer labs to work through the example that we’ll be using for the rest of the week. Two of the more interesting items that we’ve covered today (apart from working through the ‘Build a system to play blackjack’ example are:
- Comparing Test Driven development to Design by contract. In this comparison, the code to setup your unit tests are equivalent to your pre-conditions, and the assertions within the JUnit tests are the post conditions.
- Separation of concerns on get / set: each should do one thing , and one thing only
The worked examples from today (Mock Objects and Video Store) are also very well thought through and get the point across.
Not much to report, given that I was in Leeds on a business trip … but I’ll post the ‘catch up’ on what happened today as part of Day 2.
Will update this with feedback from the ‘How to talk to your boss about agile’ event, but in the meantime, here is all the slides and links to articles used in the Agile presentation.
More information here on ‘Google scrambles to plug Gmail hole’
Two things to take from this:
- Even Google Makes mistakes when it comes to Security
- Hosted Applications can be patched and rolled out much faster than traditional ones. Can you imagine a problem with your version of Microsoft Office being fixed ‘about three hours later’?
We’re giving a talk about ‘how to talk to your boss about agile‘ for the Irish .Net Developers Association next Tuesday in Buswells hotel Dublin.
More details (including the slides themselves, as a preview of what you are missing) are available here in powerpoint, openoffice, pdf and flash formats. The slides explain how 4 pictures of bridges can explain the difference between Ad-Hoc , Predictive, Agile and XP projects. No , really , you do want to check this out.
Links to a lot of the sites / articles / tools used in the presentation are here on Del.icio.us. More posts on this blog about using agile techniques on projects are here.
The Bridges are:
- Old Drogheda Bridge from the 1200’s - Quick and Dirty or Ad-Hoc project. Got the job done , and fast . Was patched a load of times, but eventually fell down under the weight of the traffic.
- New Drogheda Motorway Bridge - Predictive Projects. Very easy to specify what you want (I want a bridge going from A-B to carry a motorway) and very easy to know when you are finished.
- Drogheda Railway Brigde - Agile. Once the longest Iron Girder bridge in the world.Built in the 1850’s and the spec has kept on changing since. This included a complete rebuild in 1925 without losing a single days traffic. How’s that for unit testing?
- Bungee Jumping off bridge in Queenstown - Extreme Programming (XP). Great fun if you’re doing it (and can be pretty effective), but scary for anybody watching.
As a sample of some of the pictures (which include lego people showing everything that can go wrong on a team), check out the image below.
.
Image from
TheBrickTestament.
UCD (University College Dublin) have just confirmed that the next module in the MSC in Software in Software Engineering will be Agile Software development, with the module provided by Exoftware - them that are into Extreme Programming in a very big and very effective way.
Ironic then , that I’m meant to be presenting on Agile Software to the Irish .Net Developers Alliance (INDA) the week before -:-)
NoUnit is an open-source code coverage tool that shows you the effectiveness of your JUnit tests.
After a suitable pause , I’m now thinking of starting work on the next version of NoUnit. Some of the features I’m thinking of including are:
- Eclipse Plugin , so that you can run NoUnit code coverage reports as easily as you do JUnit tests in Eclipse.
- Support for JUnit 4 and Java 1.5 Annotations
- Support for EJB 2.0, EJB 3.0 and Spring - currently NoUnit only shows direct calls between Java classes.
- Various outstanding bugs and change requests from users.
Is there anything else you think should be included? Leave your comments here.
NoUnit is an open-source code coverage tool that shows you the effectiveness of your JUnit tests.
After a suitable pause , I’m now thinking of starting work on the next version of NoUnit. Some of the features I’m thinking of including are:
It now seems obvious that the Healthcare Payroll system was destined to fail. If you were working on the project, I’m sure it felt very differently at the time. How can your projects avoid a similar fate? While IT may sometimes seem disconnected from reality, the following guidelines show that ‘Real World’ lessons still apply.
- Know what you want and stick to it. If you’re building a house and change the plans several times the builder is going to fleece you, no matter how low the initial quote was. The same goes for IT Projects - if you change your mind after the price is agreed, you’re going to pay more.
-
If you don’t know what you’re doing , find a friend who does. I know very little about houses, so when I was buying my own I got a friendly surveyor to check it out. With IT projects, this ‘friend’ should be genuinely on your side, and have something to lose (e.g. financial or reputation) if things go wrong.
- Little and often is better. Like exercise, smaller projects that deliver results little but early are best. If the results are good, try a second (and third) round to add more functionality based on the feedback from users.
- It’s been all done before. Tailored suits cost a lot more than ready-made ones - and most people are happy with a ‘Good enough’ instead of ‘Perfect fit’. There are literally thousands of ‘off-the-peg’ computer systems out there ready for final alteration to what you need.
- If you don’t understand the answer, ask more questions. Thankfully the days we sat and nodded at the Doctor’s Latin words are long gone. IT Consultants may sometimes speak a different language, but if they can’t explain what they’re talking about in English that you understand, the chances are they’re trying to hide something.
- Don’t build on sand. Like houses , projects need good foundations. For IT Projects , the good foundations are sound knowledge of the Business Processes being coded into the system. Changing processes and changing IT systems at the same time is like building on sand.
- Sometimes the tortoise wins the race. Unless your entire business model is built around being the very first to market, then being a tortoise and letting others race ahead has very big advantages. Not only can you learn from other people’s mistakes, but the chances are you’ll get it at a much reduced cost - For example websites now cost a fraction of what they did during the dot.com boom.
- Use a safety net. When building houses, often the first thing to go up is scaffolding, for safety reasons. The equivalent safety net in IT is called ‘Unit Tests’. Not only do they help you get there faster, but they let you know if you’ve broken something you’ve already built.
- Be a good poker player. Good poker players never give away valuable cards. For IT projects, owning all cards mean just that - make sure that you have full rights to the solution so that you can still move tables and use a different supplier. Even if you never make the move, knowing that you can is an effective bargaining chip.
And finally …
When you are in a hole, stop digging. The decision to call a halt to the projects was no doubt a difficult one, and is to be applauded. Too often, the temptation is to keep on going and hope things will turn out right. Recognising problems at an early stage means there is more chance of being able to fix them.
Over on the KnowledgeBase , the outline of the presentation ‘How to talk about Agile to your boss‘ is begining to take shape.
The presentation is due to be made on the 7th March to the Irish .Net Developers association at Buswells Hotel in Dublin.
Take a look at the presentation (in progress), and leave comments here with your feedback!
The Google Blog has a nice page outlining how they use Crowd Wisdom to predict when , and how their internal projects will turn out.
The basic idea is that project participants and observers are given electronic ’shares’ in the project. People are then free to buy and sell these shares based on what they think is likely to happen (the new office opens on time, a new project fails to deliver).
While it’s a game, it’s been proven to be more accurate than traditional areas of forecasting, probably because it gets input from so many people.
Could this tool predict your project success?
