Dave Thomas paid a visit to Brisbane to present his talk Maximum Software Productivity – Breaking The Rules! at the Microsoft office at Waterfront Place. He set the scene by suggesting the last time he gave this talk he was innundated with hate mail from agilista and objectas! Dave promised the slides would be posted, but I have not been able to locate them if they have. Here are my notes from the session:

• tired of need to get agile and need to get objects – both good, but got nothing from it, where is the value?
• objects good, agile good, but are we any better off?
• most software late, bloated, poor to maintain
• business does not define requirements well, don’t engage or talk to the customers (NEHITO visits – “Nothing Ever Happens In The Office”), insist on the industry norms because that is what everybody else is using
• storypoints – training wheels for people who don’t know how to estimate
• IT does not estimate well, do not build continuously or automatically test (need to be prepared to write a big cheque), also fixed in technology
• if not ready to do TDD, just stop! Scrum will only make you feel good
• need to change the rules to be competitive
• living in legacy due to OO mud ball – legacy is code where there is no tests (see Brian Foote – Big Ball Of Mud)
• objects too hard for normal people, first thing to be voted off the island should be Hibernate, objects don’t work for lots of things (queries, rules, transformations, etc…)
• 80% of objects are CRUD – no objects except for the junk in the middle – just data, no simulations or data model – taking a solution and making it complicated and slowing it down
• frameworks – so many to choose from, new versions, latest things, lots of dependencies
• dependency injection is proof of how much we have screwed up objects
• object libraries are unstable and languages are complex (attributes, generics, concurrency)
• very few people use interfaces properly and keep them stable release to release
• little reuse – promise not a reality
• serialization carries all of the baggage of the objects contained within
• objects suck up performance and memory – bulky and computationally expensive
• objects cumbersome and slow for multi-core processors to run efficiently
• objects are sequential and parallel
• Java application will be 4 to 5 times slower than PHP, because objects are slower
• can we shorten software value chain – shorter, faster, cheaper – Facebook built in PHP but the money rolls in
• agile shows predictability and productivity but zip about quality
• agility is good, but in Java it is very difficult to change the code quickly
• scrum increases morale (everybody feels better), but makes no difference to quality unless doing TDD
• lean thinking – software waste – if not prepared to spend $2 million to do continuous integration and TDD then they are not serious about their software output and quality
• don’t go to meetings unless it is increasing the bottom line – will it help ship code?
• how to make zero defect code? Don’t ship anything!
• lean – simple – why am I doing this? – do we need a new framework? – NO!
• staff a team with people who have shipped software (have a track record)
• fix price your consultants and enforce that they make delivery with acceptance tests – pay when they pass
• reward people on delivery, not how long they work
• tangible requirements – story on the front, acceptance criteria on the back, start with acceptance tests, they are more valuable
• envisioning – what the developer sees is not what the customer wants
• agile great for prototyping – building small requirements on the fly
• a backlog filled with lumpy requirements will burn out designers and product owners – original Scrum paper said sprint 0 should be 3 months – envisioning
• architects – not a job, a role – should be able to code
• some companies pay senior developers same as VP
• extreme design – four hours to design software and hardware and cost it – after a few, you can get close and find out quickly what you don’t understand
• serious engineering needs design
• API first – design the architecture, should always be able to get architecture from the code (push a button)
• need API’s versioned in the code
• want to close gap between needs and solution
• a picture is 1,000 words, a table 200 and a diagram 50
• table driven programming – easily understood, easy to refactor, easy to consistency check (look for missing data), easy to version and diff (just data), data driven can be changed live in a running instance
• integration – talk to old systems use RSS/ATOM feed (almost all old systems will give a feed for each transation) then you can talk it without custom api’s, REST/JSON your services or use ODBC as a simple interface (its not just for databases), use mashup tools to deliver an integrated application view
• use scripts to save time & dollars – most software gets thrown way even before turned on, C# and Java too heavyweight, Ruby, Python, PHP, Groovy, Clojure, can easily leverage cloud services and existing services
• productive languages – LINQ and Reactive LINQ (Haskell underneath), Erlang (good for swicthing and moving traffic, highly efficient), F#, Ruby, Scala (a better Java), Kleisli (bioinformatics), Clojure
• Everybody should read “The Wizard Book”, Structure and Interpretation of Computer Programs by Abelson, Sussman, and Sussman
• hardware is cheap, cloud is cheaper – all interesting data is in memory, databases are just journals and don’t really exist, Google does everything by brute force search (eg. translation), speed now means complicated stuff can be done easier and cheaper
• data driven – massive storage means we can store it all very cheaply, run smart algorithms to determine best value customers because we have all of the data, recommendation engines (NetFlix), Net Promoter, complex event processing (open intelligence), real time financials (no end of month financials, know state of company all of the time)
• query oriented programming (QOP), Greenplum, Q, Aleri (basically extended SQL dialects with functions) and other functional languages
• array VM’s – better than object VM’s – always boxed, simpler garbage collection, support all data types (array of stuff is an array of stuff), VM can be small (just an interpreter), arrays are column stores already and trivially serialised, take less space and programs concise and compact
• best practices for functional programming – agile , refactoring tools, FindBugs / Lint
• challenges for functional programming – get out of math phobia, different way of thinking, need to write literate and understandable code, think in functions
• yesterday and tomorrow is always wrong – if you get more bang for buck and competitive advantage, why use existing technologies, if you believe IT is strategic you need to do something strategic with it and dare to be different
• lost of old things work, lots of new things work well, get out of agile and OO box