Tag Archives: Refactoring

Episode 171 – Beyond Legacy Code with David Bernstein

by

1

Craig is at Agile 2017 in Orlando, Florida and speaks with David Bernstein, author of “Beyond Legacy Code“, and they chat about agile technical practices:

  • Agile does have something to with software development
  • Agile 2017 talk “Create Software Quality
  • The real value of Agile is in the technical practices so we can build iteratively, but still very few people practice them
  • The future is already here, but it is not very well evenly distributed – the same applies to Agile
  • Companies are being consumed by their technical debt and they don’t even recognise it
  • What is always cheaper in the virtual domain is building quality
  • Continuous Integration makes the most painful thing in software development (integration) our greatest asset – this in turn gives us feedback
  • We don’t necessarily know there is a better way to do things – but there is a better way to do things
  • We traditionally think of software as a write once event, but it is write many – users want it changed
  • We think procedurally so object oriented code often ends up being procedural with a class statement wrapped around it
  • Test First Development – very few developers know how to write a good test because they haven’t been taught, it was intended to assist with refactoring
  • Studies show about 10% of people follow the Agile technical practices like XP, and only 10% of those are doing it correctly
  • The mindset of testing is different to the mindset of coding and they are mutually exclusive (in the same way we need editors when writing a book)
  • Refactoring is at two levels because we learn in chunks – we need to do while doing test first as well as in the large
  • “The Art of Agile Development” – spend 10% of your time refactoring
  • Communication – say what, why and for whom before how – we think in implementation
  • CLEAN code – cohesive, loosely coupled, encapsulated, assertiveness and non-redundant
  • Need to understand what quality means in software
  • Troy Magennis talk “I love the smell of DATA in the morning (Getting started with Agile Data Science)“

TheAgileRevolution-171 (34 minutes)

Advertisement

Episode 149: Continuous Delivery with Dave Farley

by

1

Craig, Tony and honorary Revolutionist Pete Sellars are at YOW! Conference and sit down with Dave Farley, co-author of “Continuous Delivery” and they chat about the following

  • There are anti-patterns with doing XP at scale, continuous delivery was born from the learnings from that
  • Continuous delivery is just extending continuous integration to more of the software development practice (and continuous integration requires test driven development)
  • Continuous delivery works because it is the application of the scientific method to software development
  • If you work in an iterative, imperative, experimental way and you take continuous learning seriously and take cycle time as a serious measurement you will naturally drive out agile, lean, systems theory and DevOps
  • YOW! 2016 presentation “The Rationale for Continuous Delivery“
  • Most common two ways to introduce continuous delivery to your organisation – need to get cover from senior management to make change or you do it secretly at the grass roots – the fast feedback cycle is important (build feedback in about 5 minutes and ready and deployable in about an hour)
  • DevOps is a terrible name – we are talking about collaborative cross functional teams and it is more than just developers and operations
  • Continuous delivery is focused on shortening the feedback cycle from having an idea to getting the idea into the hands of users and figuring out what our users make of the idea – that’s software development, to do whatever it takes
  • Continuous delivery is working in a way so that my software is always in a releasable state, continuous deployment is if all my automation says my software is in a working state I can just automatically push it to production
  • We have data to show that continuous delivery makes high quality software faster, creates more money for the organisations that use it, reduces defect rates significantly and makes people working in that environment happier
  • It changes the way you design, approach databases and the way you test
  • Scott Ambler’s “Refactoring Databases” book
  • Continuous Delivery tools still aren’t mature enough
  • The deployment pipeline is a seriously strategic resource because it is your only route to Production – need to be able to version and test it like any other Production code
  • It’s as much about the culture of the team than it is about the technology, it frees teams up to do experimentation

TheAgileRevolution-149 (40 minutes)

Episode 145: Working Effectively with (Legacy) Code with Michael Feathers

by

1

Craig is in Atlanta at Agile 2016 and catches up with Michael Feathers, author of “Working Effectively with Legacy Code” and they talk about the following:

  • Working Effectively with Legacy Code originally started as a book about Test First Programming but morphed into a book about the techniques for refactoring code in legacy systems
  • The Pinned Progress Curve – for many people there is no incentive to change so the mean gets larger between the status quo and good practices
  • Agile Alliance Deliver:Agile conference
  • Organisations that have technical founders have a very different character to their work internally, need to make knowledge of the quality of software more pervasive – the business need to understand more about the technical side, and the developers need to understand more about the business
  • Code that has excessive error handling typically has other design problems – benefit in thinking about whether certain things should be treated as errors or not
  • Entropy happens in all systems, including code, so technical debt is not a surprise, need to make the case for hygiene, putting a dollar amount on technical debt does not add much value
  • Use low impact probing to determine whether code is dead
  • Potsel’s Law – an implementation should be conservative in its sending behaviour, and liberal in its receiving behaviour
  • State of quality is improving and there is more recognition to build quality in
  • Property based testing is becoming more prevalent as we move from object oriented to functional languages
  • Holacracy was designed by a software person, Sociocracy talks about applying democratic principles to governance, these are all interesting experiments
  • It can be hard to recognise if something is intrinsically difficult or not something you are familiar with
  • We weren’t really battling waterfall, it was the lack of any process at all…

TheAgileRevolution-145 (33 minutes)