I have been a developer for more than a few years now and so have been involved in different kinds of software, teams and software methodologies and “none-methodology”. I have worked on teams where the software development process mirrors closely the traditional waterfall model where you just receive a set of requirements/features which are funneled through by “business team” who then send in through to development team who then try to analyze and then break it down into modules and pieces for mostly the purpose of development convenience and not necessarily as it is usually delivered as one big bang release.

Afterwards, new work comes in as new features, modification to existing features and bug fixing. Most often that not because these applications do not usually have analytics and monitoring built in, there is little insights on how the users are using the application hence these features & updates end up typically driven by the (wrong) premises that more is better, or even worse random light idea bulbs by the business team. In this world, you usually end up with massive “enterprise” (sometimes this word could mean large complicated systems where the app has grown beyond the grasp of everyone and large complex things are happening behind the scenes – backend, or just multiple modules/views that just present a way to CRUD data without much thought given to the actual user experience/work-flow) system with multiple features most poorly maintained, hardly used and not delivering the value that is required. A lot of time is wasted working on things that don't matter leading to unhappy software teams & confused business team (product owner etc).

The above-described scenario is far from agile software development and definitely not Data Driven Development or Lean Programming (hence referred to as DDD/LP) the title of my post but I thought a background on how things used to be done and where we used to be might provide a good foundation to appreciate the very simple example of DDL/LP which I give later on. The practice is simple in itself and most of the effort is probably spent in pushing for a change in mentality and getting the stakeholders buy in.

Data Driven Development in this post refers to a kind of software methodology where new features and updates to existing features are based on insights gathered from metrics and analytics on how the users interact with the system. Heh, you might want to argue how do you get data when there is no app? Do we have a chicken and egg problem here? No, usually for a new project you might have a UX team mock up something that can be used for user testing and data from this can be use for deciding if the new feature can be expected to deliver value. Obviously, I have simplified but the key here is that there is some scientific backing to the new features/updates that gets prioritized in the teams work stream.

Lean programming is how you can deliver this fast and in small usable bits such that you can quickly get feedback on how this is performing and then use this data gotten back to inform the direction of the work needed, this could be enhancing the feature, providing it to more classes of users, providing related features or sometimes having to analyze why new feature is doing badly, removing it and then learning from this to inform future work. Lot of learning is happening in LP/DDD and this is treated as first class citizens.

“heads up… the XYZ is performing beautifully! will share the numbers shortly…” – Product Owner on our team slack channel

So I have a fine example of data driven development & lean programming in real life but I don't even know if my followers is right audience

— temitope (@topriddy ) January 27, 2017

Recently, I've been opportune to work within a small agile team within a nice company and I've been able to see, learn and practice a different approach to software development where we use data driven development and lean programming. This has gotten me excited again about software development, nearly enough to be drafting this article before 7am after a long hiatus from writing to describe a very simple real life example of DDD/LP work I was involved with.

• Product Owner, UX, analytics gathered metrics from site and discovered a user patterns in the site that pointed an opportunity for a big improvement by adding a small feature to the page that they believed would help conversion.
• A mock-up is created and some user testing is done to gather some feedback. The results of this is presented to the team and forms for a pitch for the work
• After estimating the work needed, this feature could be delivered to two types of system users and could contain at least two “detailed” type of information. LP is applied and it is decided to break this down to deliver for first type of system user – User A, and only deliver initially the first type of Detail I.
• This is then developed and tested by team
• A/B testing approach and feature toggle was built as first class citizens to this. Analytics was tested to confirm it works and right type of information is gathered!
• Deployed and performance monitored
• Feedback was positive so justifying the need for another iteration where this is delivered to larger audience.
• Consider delivering for second type of users
• Bonus: Feature needs to support/work for your top users and their devices based on the data from analytics

This approach to software development, probably an anti-climax to the article especially if you practice this already actually allows you to deliver value to the users, improve your conversion rate, and most importantly manage your limited resources by helping prioritize work that needs to be done.

You might also reinvigorate the enthusiasm of the software development team like me. :D

(Irresponsibly blaming any typo and bad writing in this article to dancehall music playing in my head after a fine night out and the two red bulls I had. Just want to post this now and come back and review later).