Wednesday, June 26, 2019

Software Architecture for Developers by Simon Brown

A book mainly addressed to developers, especially to those who want to switch roles to software architecture, in an agile environment.

Read more on my LinkedIn article.

Tuesday, June 18, 2019

SQL SELECT / UPDATE formatting trick

Many times I'm using this very simple SQL formatting for both SELECT & UPDATE (usually with MS SQL Server using SQL Server Management Studio or some other tool, interactively):

SELECT Count(*) -- TOP 20 A.*
-- UPDATE A SET A.Field1=B.Field1
WHERE <condition>

By default, all query is just a SELECT Count(*) which doesn't change anything but give you an idea of the number of records selected or updated later.

If I comment out the first part to something like this:

SELECT /*Count(*) --*/ TOP 20 A.*

it gives me some records that will be updated.

Then just undo the change and select the query from the UPDATE and execute the selected text. Also, the number of records updated should match the number displayed with Count(*).

It's like 3-in-1, which can easily go in comments of the ticketing system or emails.

Achieving DevOps: A Novel About Delivering the Best of Agile, DevOps, and Microservices

A book by Dave Harrison and Knox Lively.

If you are interested in modern software development, with 2019 methodologies, practices and tools, especially using Microsoft technology stack, this is the book to read. It may have something for you, as it covers a lot of ground of Agile & DevOps, but also everything else that comes with them, chapter by chapter, section by section: teams, processes, tools, testing, automation, infrastructure as code, configurations, continuous integration, continuous delivery & deployment, life / work balance, and more.

Continue reading on my LinkedIn profile article.

Saturday, June 15, 2019

Accelerate: The Science of Lean Software and DevOps

A review of highly recommended book Accelerate: The Science of Lean Software and DevOps (2018), by Nicole Forsgren PhD, Jez Humble and Gene Kim.

It's based on Puppet State of DevOps Reports between 2015 and 2018, which I also recommend (read 2018 report here)

If you think of using Agile & DevOps practices to accelerate software development and continuous delivery this book is a 'must-read'.

Read full article on my LinkedIn.

Sunday, May 19, 2019

Agile story points for bugs

Asking if bugs should have story points is a bit controversial, although most answers are 'yes, they should have'. Jira, for instance, doesn't show by default story points field for 'bugs', for that very reason not to assign some, but the question how to do it was asked many years ago, with simple answers.

If you consider definition from Agile Alliance and consider points as a metric for velocity, than yes, it makes sense.

It was also asked many times on various boards and forums, like this one on StackExchange, from where I personally like Joppe's answer:
You should not give points to bug resolution. Consider the fact that the bug comes forth from a story where the developers already earned points for completing the story. It should not receive points again where it actually shouldn't have earned the points to begin with.
Bug fixing should have a negative effect on velocity. Otherwise dropping quality ends up being rewarded with an unaffected or even increased velocity!

Regardless of many 'yes' answers there are also a lot of people, like me, who thinks the answer should be 'no', for a very important reason: 1st principle of Agile, which states
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Let's ask a mode difficult (related) question: Are bugs fixing added value to your customers (or business)? The simple answer is yes, but when you look deeper into it don't you think those bugs were some broken promises or expectations in the first place? Bugs don't add value, on the contrary.

You promised something or a specific feature was expected by customers or business which was not yet delivered. Of course it takes time to make it right, maybe some aspects were way too complex and discovered only later, but still a broken promise.

That's exactly the 'technical debt' people are talking about, and ways to reduce it is exactly a responsible way to find and fix bugs. The theory says they should reduce their numbers over time, but is this right in practice? How you reduce them is you are treating bugs like feature and award points to them which increases velocity? A reduced velocity because of bugs is an immediate measure of the quality of work, and can be easily charted over time. How is your trend for bug fixing?

Saturday, May 11, 2019

Agile team leaders and DevOps

I'm currently reading Microsoft's Open edX course AZ-400.7 Designing a DevOps Strategy where, after an extensive presentation of Agile manifesto, principles and methodologies, in chapter 2 Planning Effective Code Reviews says:
Team leaders need to establish and foster an appropriate culture across their teams.
What team leaders in Agile? Agile roles are clearly defined (in the context of Scrum methodology, which in practice almost always go hand in hand with Agile), and there is no 'team leader' in it, rather the entire development team is empowered and entrusted to self-organize itself.

Searching Google for 'agile team leader' will render various pages where people is explaining that's a bad idea and shouldn't happen in Agile. I beg to differ, but that would be another story, someday.

On the other hand, how the whole DevOps new ideas embrace agility? I see some other pages comparing the two, and many times there is a tiny 'vs' between them, "Agile vs DevOps", suggesting them as competing terms.

It's true that Agile focuses mainly between communications and relationships between business (stakeholders and product owner) and development team, while DevOps focuses on that dev team one step further, seeing them as proper software development team and operations team (each with its own goals).

And is also true that DevOps is agile (with lower case "a"), is even mentioned somehow ("continuous delivery") in first principle of Agile Manifesto, but where in Agile methodology talks about 'DevOps'? DevOps is more than just a simple notion of continuous delivery, it encompasses principles, processes and tools dedicated to it. Maybe we'll see more of it in future updates of Agile methodologies.

Until then, I'm reading more of something else I come across: Disciplined Agile (DA). One of its layers is clearly named 'Disciplined DevOps'. It looks like DA is more agile than Agile. One thing I like about it is that has a holistic approach for entire agile enterprise, not just IT development department. Another is that recognize some other important (primary) roles, like architecture owner, team leaders or DevOps, as well as supporting roles, all within an agile framework or toolkit, as they name it.

I'd definitely read more about DA[D], as it looks very appealing to me, especially in the context of DevOps.