Lean Beliefs

  • Home

Tag Archives: Continuous Delivery

30 mins 1 on 1 discussion (more or less) with Mary Poppendieck

04/02/15 / pcsontos / Agile, Lean, Software Engineering / Continuous Delivery, DevOps, microservices

Last week I attended the optionalconference.org event that was again a great opportunity to meet Agile-minded people and hear about lots of interesting and useful stuff. Clearly the biggest highlights were the keynote speech by Mary Poppendieck and the 30 minutes I could spend later on talking to her, first 1 on 1, and later in an ever growing group of people.

The speech was a funky combination of talking about scaling organizations (probably this was the part that she was “ordered” to talk about), and some really cutting edge topics around Continuous Delivery and DevOps.

In our 1 on 1 coffee-break discussion of course she emphasized how pull-based Lean systems are much better than having backlogs and sophisticated planning activities. This one was not really surprising, given that she “invented” Lean Software Development. The interesting part was, however, when she started to talk about databases. In her theory, big central databases (no matter how fast and efficient or “distributed” they are) are bad, because they enforce tight coupling of business logic functions built on top of them. In the era of microservices, you can react to customer demand of new functionality (“pull”) fast enough only if your services don’t have to be integrated into a big system all the time, but they can work quite independently. Of course data integrity should be kept, and for that, eventual consistency mechanisms exist.

So no matter how good DevOps you have, if your architecture is too complex, it can be the other (dark) side of the Continuous Delivery coin.

Agile: How different and still how similar…

03/09/15 / pcsontos / Agile, Lean, Software Engineering / Continuous Delivery, estimations, scrum, technical debt

Recently I’ve met several people from a small software company. As lots of startups in my country, they used to start their business in the professional service area, but building on more and more similar successful projects, they have started to productize their software.

They are just in the beginning of adopting an Agile process, and talking to them revealed to me (in spite of being in a quite different area of the software industry and having a company 2000 times smaller than the one I work for) how similar challenges do these people have compared to what I’ve seen in the last 10 years:

  • Struggling with upfront estimations often proving to be wildly wrong
  • Learning that hundreds of pages of specifications are worth much less than frequent feedback from customers
  • Priorities of features changing frequently, both needing to serve a long-term product roadmap and short notice requests
  • Stakeholders having vastly incorrect assumptions about complexity of software engineering work
  • Finding the right balance between perceived speed and real speed, like spending overhead effort on removing technical debt and doing test automation for continuous delivery (utilization vs lead time)

Surprise, surprise…

The year of…

01/07/15 / pcsontos / Agile, Software Engineering / Artificial Intelligence, Big Data, books, Cloud Computing, Continuous Delivery, DevOps, HTML5, Internet of Things, Mobile Apps, self testing code, Speech Recognition, Wearable Gadgets

Happy New Year Everyone!

I thought I would write my first blog post this year about what you may have read plenty around this time of the year: the “year of” topic. Not just the upcoming year, but the last few ones as well, from a completely subjective standpoint.

2010: The year of SMARTPHONE – I got my first BlackBerry, WHOA! We also started to work with iPhone, and experiment with Android. A whole new world, definitely.

2011: The year of TABLET – BOOM! The iPad came and conquered. I still don’t know what tablets are good for, besides the kids playing games, and me watching a movie with my lovely wife in the evening, and I especially don’t have a feeling for phablets (they are not big enough, but they also don’t fit into your pocket), but I don’t have to sympathize with everyone, after all half of the world has an IQ lower than 100 (by definition), and I have at least 101 – how humble I am :).

2012: The year of HTML5 – Peek of the cross-platform mobile app development struggle. Even though developing software for iOS and Android and Windows is 1x + 1x + 1x == 3x effort, and developing cross-platform software with JavaScript and various HTML5-based frameworks is 5x due to the technology being not only premature but having been invented for a completely different purpose, and the result being highly inferior, some very smart people like the idea very much, so we live with it, fact accepted.

2013: The year of ENTERPRISE BIG DATA – People realized that hardware is cheap and good enough for completely redefining corporate system architecture (forget data warehouses and batch processes), so we in SAP ended up being in the HANA-fever. We still run ahead with 41 °C fever, and eventually the whole world will be heated up (further global warming granted).

2014: The year of CLOUD – Instead of emphasizing how much the business model of the whole software industry is turning upside down, I would take two examples from my private life. CDs can be retired, listening to music while driving is by now Spotify-only. What else. Grocery shopping is done via Out of Milk, the whole family cloud-synced all the time (and btw, speech recognition finally became mainstream (when I say something into my iPhone or my wife’s Samsung Galaxy with my Hungarian accent (and btw2, even in Hungarian), it recognizes well)). Life will never be the same again.

2015: The year of…
– NOT IoT – I think it’s not there yet, lots of edge use cases available, but no mainstream killer apps predicted for the upcoming year. Maybe in 2016.
– ESPECIALLY NOT wearables – If you are not a runner, what are they good for, honestly?
– EVEN MORE NOT AI – just take language translation for example: Try out Google Translate and you’ll see what I mean. Bad joke still.

So what then?

I think 2015 will be The Year of DevOps in my little world of software engineering. In 2013 Continuous Delivery was a nice thing to hear about, in 2014 it was something we wanted to experiment with, and in 2015 it will be a matter of life or death. We should forget about the distinction between developers, testers, release engineers and operations. We have to work together on fully automated solutions that build, test deploy and monitor software, and thus provide the dynamics everyone expects from software that runs the whole world in 2015.

Sustainable self-destruction of software development projects

12/03/14 / pcsontos / Agile, Lean, Philosophy, Software Engineering / Continuous Delivery, Definition of Done, technical debt

Sustainable self-destruction is the golden mean lifestyle of most of us as individuals, the way we balance between too short term and too long term thinking and behavior.

We don’t like extremes. One of these extremes is total self destruction. If someone doesn’t care about the future and only considers having fun in the present or the short term, it certainly leads to serious negative consequences in the mid/long term. Consider hard drug addiction (that leads to dying young) or robbing a bank for having lots of money “easily” (that usually leads to spending a very long time in prison).

The other extreme is constantly pursuing ethical or religional perfection (and I’m not speaking about which religion is “right” and which one isn’t). If someone has total temperance and always behaves according to strict moral rules, it is definitely a short term competitive disadvantage, but in the long term it is perceived to lead to bigger harmony in life (and/or afterlife, whatever). Most people don’t like this philosophy either, as it is perceived to be less fun.

Most people usually try to balance this out, and have a lifestyle that I call sustainable self-destruction. Try to gain as much as possible (money, power, popularity, amusement etc.) as easily as possible, preferably not breaking the law in a very visible way and not hurting other people at least as much as our somewhat still existing conscience is still OK. Consider the health of ourselves and our planet. Sometimes even donate our time, energy or money to a noble purpose. For some people this balance can be quite a stable thing, some others keep going back and forth, but it’s basically the same thing: we aim for avoiding both too short and too long term thinking.

You may have guessed from the title: here comes the analogy with software development projects.

First extreme: too short term focus – We run towards burnout, technical debt, sacrificing our private life, code maintenance hell later on etc. for the fun of gaining quicker promotion or just getting bigger credit for delivering an enormous amount of features too much in a hurry, not caring about good architecture, code quality or having a great team.

Second extreme: Agile / Lean perfectionism – Always do pair programming, TDD, don’t release anything until all the 42 elements of the Definition of Done are fulfilled, this way most probably losing credibility with top management, failing to use windows of opportunities, not meeting customer expectations regarding deadlines (yes, deadlines), exceeding project budget and so on.

Traditionally, most good developers would prefer something closer to the second extreme, while project managers would vote for something closer to the first one. So in the end we arrive to some kind of a golden mean here as well. When we have to rush towards deadlines and accept ambitional project scopes based on aggressively (or even arrogantly) estimated backlog items, we do these to keep customers or product managers happy. However, when we don’t have to hurry too much, we “do our best” to increase automated test coverage, decrease technical debt, do more code reviews, improve the documentation etc.

This is again usually a constant struggle of back and forth. My theory (and wish) is that as we move towards continuous delivery, the amplitude of these back and forth waves decreases to an acceptable level.

Life, the universe and everything about lean software engineering

Blog by Péter Csontos,
a nice guy from Hungary

twitter: @pcsontos

Recent Posts

  • The only messaging platform that really works: E-MAIL
  • Dear Twitter!
  • It has begun
  • My post in Wait But Why’s “Dinner Table” discussion: How should we do government on Mars?
  • On the benefits of unit testing
  • The web as application runtime platform? Come on, we have to grow up.
  • Functional programming: “expression was too complex”
  • Software architecture is dead, long live software architecture
  • Lean Startup vs The Innovator’s Dilemma
  • The art of micromanagement

Tags

Artificial Intelligence Big Data books C# Climate Change Cloud Computing Coding Kids Continuous Delivery Definition of Done DevOps estimations eXtreme Programming HTML5 Internet of Things Java kaizen kanban Lean Startup maintainability management Mars metrics microservices Mobile Apps programming languages Recruiting refactoring Robots SAP scrum self testing code social media Space Speech Recognition TDD teamwork technical debt The Innovator's Dilemma unit testing Wearable Gadgets

Categories

  • Agile
  • Lean
  • Management
  • Personal
  • Philosophy
  • Software Engineering
  • Uncategorized

Archives

  • May 2018
  • September 2017
  • April 2017
  • October 2016
  • June 2016
  • April 2016
  • February 2016
  • November 2015
  • October 2015
  • August 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • January 2014
  • December 2013
February 2019
M T W T F S S
« May    
 123
45678910
11121314151617
18192021222324
25262728  

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org
© A WordPress Site
TwitterFacebookLinkedIn