Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Recorded at:
Presented by Luke Francl on Jan 02, 2009
Agile Development: A Manager's Roadmap for Success
Architectures Behind Facebook, Skype, Sky.com, Bwin, League of Legends @ QConLondon
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
TDD is not just about testing, it’s a design technique.
Interesting presentation and good sense of humor while presenting
Agreed.
It is really astonishing where the scripting languages are getting too and selling it progress....
(Unit) Testing is not about getting all bugs at once. It's about getting (and fixing) bugs fast (even if you don't do TDD).
When you write a code with test, other developers can go in and change it and see if they broke anything functionality that you did.
And if during the course of usage, a bug arises, you can debug your code easier if you have tests all around. Because those states who are not tested are most likely be the suspect (thereby decreasing the states that you have to go through).
Having unit tests will not guarantee a bug-free system. But it should speed things up in fixing them.
... for real-world feedback. It is a substitute that is repeatable and instantaneous and with no damage done.
Exposure to the real world is actually better, since it better (very effective, actually) to find errors in the specifications. However, making errors in the real world, when you are developing money-moving software with more than 10 digits for the amount, is not so practical.
Agreed.
Without good unit testing, refactorings are suicide.
I will take this (humorous but well argued) presentation as really a re-affirmation of the valuable but within-limits benefits of unit testing. As with any good thing, we have to be careful to clearly set expectations of its limitations: I agree that metrics get sometimes out of hand and become meaningless, I also agree that you can't test what wasn't implemented and should have and that unit code testing does not replace end-user testing.
With that said, code testing does improve quality of implemented code and features (in my own experience), it provides a firm base to validate the aging code (as during refactoring) and new features against and, not lastly, provides a form of code documentation (most importantly the intention behind the code -- not just mere comments in code -- which will be valuable years later, as some code runs and it is maintained by many people for long periods of time.) I would not discard here the sense of confidence good tests passed inspire in developers, especially important during difficult project periods. I would also think that scripting/dynamic languages need more testing because of the absent/reduced compiler-supported validation. The problem with insufficient negative case testing -- testing for what could go wrong -- comes from the fact that, in reality, too little attention is given to that -- starting with requirements, use cases, etc -- at a project/product technical and management level, and that is something we can do something about.
I have not seen code reviews ensure quality of code in a sustainable manner, either as a code reviewer or reviewee -- unless if that is part of pair-programming -- but that could be subjective.
To conclude, I believe we should be doing (more) testing but understand and act upon its limitations and benefits vs. costs for each particular situation.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
8 comments
Watch Thread Reply