Learnings and reflections from Extreme Programming Conference!

Alvin Toffler, renowned American author, known also for his works discussing the "Digital revolution" once said "The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn."

Hello,

At outset of my career I chose not to be modern illiterate :) hence I keep learning aggressively whenever I get chance, keep unlearning what is not relevant and keep relearning stuffs whenever required. With learning as a prominent goal in mind, I had a hectic but really productive learning weekends recently. It started with two days' workshop (24-25th July) on "High Impact Presentation" by Dale Carnegie Training conducted by Mindtree. Then two days' workshop (8-9th August) on "Extreme Programming Conference" by industry experts again conducted by Mindtree and finally attended "Judges Training Program" on 10th August conducted by Toastmasters International.

Out of these trainings I underwent, I thought it's my duty to share the knowledge I gained particularly from " Extreme Programming Conference"  (http://www.xpconference.in/) since it was Mindtree who gave me the opportunity to attend it and it would be relevant for most of you (needless to mention that you can contact me directly if you want me to share my experiences on other trainings as well :) ). I think it’s enough for we developers to know the terminology, rest we all are expert to dig into it with our Google god J. Hence, I will at least try to share all the terminologies that I learnt in this mail and references wherever possible.

eXtreme Programming is one of the agile software development method which is leveraged to improve software quality and responsiveness to changing customer requirements. It advocates frequent releases in short cycles to improve productivity.

eXtreme Programming Values

a.       Communication

b.      Simplicity

c.       Feedback

d.      Respect

e.      Courage

eXtreme Programming Philosophies

a.       Collective ownership

b.      Continuous delivery

c.       Sustainable pace

Sessions on Continuous delivery

Key takeaways were -

a.       Architecture can strangle CD in situations like

                                       i.      Non clustered architecture

                                     ii.      Blocking requests for long running steps

                                    iii.      Hardcoded IP addresses for endpoint IPs or linked server in Database

b.      Rotating teams frequently to cross pollinate knowledge  (tools + techniques) (like DevOps)

c.       Feature based trunk development instead of using branches.

d.      Every change to the system should be releasable. Should release any version at the push of a button.

e.      Never opt for branch based development, rather user trunk based.

http://www.slideshare.net/XPConference/common-blind-spots-on-the-journey-to-production-vijay-raghavan-aravamudhan

http://www.slideshare.net/XPConference/nightmare-to-nightly-builds-vijay-bandaru

Full stack developer (FSD) (near to DevOps)

FSD is capable of performing tasks at any level on entire tech stack. It may involve

a.       Infra

b.      API/Backend

c.       Query DB

d.      UI

e.      Project Mgt

They are also called Packaged Geek in eXtreme Programming.

http://www.slideshare.net/XPConference/a-fully-packaged-geek-is-all-you-need-in-the-agile-world

Don't Branch in Continuous delivery

a.       Branching is not recommended in extreme Programming, which is being followed by company like Facebook & Google

b.      Only trunk based development is recommended

c.       Frequent check ins are allowed in single branch trunk

d.      Bugs should be fixed on trunk and merge with release branch

e.      Release branches are never merged back to trunk

f.        Release branches are short lived, frequently replaced by newer release branches

Then How to roll back in case of issues

                                       i.            Instead of branching, features should toggled on and off, as per requirement. Question - We should get rid of branching practice. Branching there are changes which may impact multiple places like presentation logic changes etc.

                                     ii.            As soon as a feature is released, get rid of it.

                                    iii.            Toggles are applied at UIs

                                   iv.            Features with no UI, the toggle will be in the app code

1.       Techniques like polymorphic substitution and dependency injection should be used to avoid crude conditional test

                                     v.            Pipelines for different permutations of toggles for releases should be setup

1.       IF either of the build fails, it implies a bad commit

Feature toggle types

                                       i.            Release - partial features, temporary

                                     ii.            Business - certain class of users, permanent

                                    iii.            Runtime - easier rollbacks, run tests with various configurations of features

                                   iv.            Build - new feature codebase is not compiled

Book Reference provided

Uncle Bob's  - Clean Coder & extreme programming in practice

The Coding Dojo Handbook - Emily

Also, I created a presentation out of it, here is the Slideshare link - 

Extreme programming - a quick and agile overview ! from Vinit Kumar Singh