Articles

What I Learned About IT From Rocking My Son

,
This adorable child has clearly taken a nap today.

In April, my wife Nicole ended up having shoulder surgery to repair a torn labrum, frozen shoulder, and a nearly detached bicept. As a result of this procedure and recovery, she currently isn’t able to rock our son before his naps. Since I work from home a majority of the time, this task has fallen to me each afternoon.

From my experience, toddlers maintain the urge to fight nap time, regardless of their level of fatigue. In fact, the more exhausted they are, the worse the struggle. After some amount of time, though, the resistance gives way to acceptance. He is not in tears or upset, just resisting taking a much needed break from an already long day.

Source de l’article sur DZONE

/par

Java Forum Nord 2018 Retrospective

,

This article is dedicated to the non-commercial Java conference that I visited on September 24, 2019, in Hannover, Germany, known as Java Forum Nord. The spoken language is German but the presentations consist of diagrams and code examples so they can be understood by the non-German-speaking readers. I want to list here the lecture which I have visited with links to the presentations and also lists with headwords.

Networking Instead of Waste: Let’s Talk — Stefanie Reinicke, Dr. Jan-Christian Dammann

This presentation was about making development teams stronger through three topics:

Source de l’article sur DZONE

/0 Commentaires/par

Project to Product: What Flows Through a Software Value Stream?

,

Throughout this series of articles I’ve explored how we need to bring the same rigor to architecting our software delivery value streams as what we’re witnessing in advanced manufacturing plants. Once we agree on what flows, we can analyze those flows to identify bottlenecks and opportunities to remove them. However, every time I’ve asked an executive-level IT leader where his or her bottleneck is, I’ve received either a blank stare or a vague answer, from otherwise extremely capable people.

To look for a bottleneck in a production system, we must first understand what flows through that system. We’ve seen many measures of software delivery flow proposed and analyzed, including lines of code (LOC), function points, work items, story points, deployments, and releases. Each captures a notion of value flow from a different perspective, but each has its limitations, especially when you consider the end-to-end flow of business value through a delivery pipeline. If my experience talking to IT leaders is a guide, from a business perspective, we simply don’t have enough consensus on this core question of what flows through a software value stream. Yet this should be the most fundamental question to answer if we are to apply lean principles to software delivery.

Source de l’article sur DZone (Agile)

/0 Commentaires/par

How to Write Software: 5 Lessons Learned from Running Businesses

,

I used to write software for a living. I did that for a lot of years, as a matter of fact. And, in doing so, I learned a lot about how to write software.

But I learned this from the perspective of, well, a wage software developer. Today, I’d like to reflect on how my view has evolved over the last number of years.

Source de l’article sur DZone (Agile)

/0 Commentaires/par

Top 12 Things That Destroy Developer Productivity

,

A lot of articles address the role of tech leads and engineering managers. One common theme we often come across is how to increase a team’s productivity. But before you focus your energy trying to increase their productivity, you might first want to consider what’s destroying it, to have a sound base on which you can build. Unfortunately, even though Peopleware was published almost 30 years ago, we see lots of teams suffering from huge productivity loss in some (negatively) remarkable ways!

No one expects a programmer to get work done without access to a computer, but there are many companies that expect programmers to get work done without access to their mind. This is equally unrealistic.

Source de l’article sur DZone (Agile)

/0 Commentaires/par

Paying Off Technical Debt: Why You Shouldn’t Go Live With POC Code

,

Let’s face it. You have debt, I have debt, the entire tech world is built on technical debt. What’s the worse thing that can happen when all of our software is built off a pile of technical debt? Well, would you drive on an overpass built with the modeling clay that was used to green light that project? Yeah, didn’t think so. In the beginning stages of building a product, it’s easier to cut corners and make quick decisions. No one sits there and says to their investors, "We understand you want a quick return on the nice big check you wrote, but we are trying to figure out if the platform should be made using blockchain or Rails 5." (Yes, I know those are VASTLY different things, work with me here).

CAST Software found the average per-line cost of technical debt to be $3.61, and for Java code, a staggering $5.42. Interesting Forbes Article

You want to build a platform, go to market quickly and get that sweet, sweet validation that users actually want what you built. I’m not here to kill your dreams or to tell you to move slowly. After all the tech industry is famous for "fail fast." What I want to suggest is that as soon as you go to market with viable product, start thinking through those long-term consequences. That time you choose X, when you really knew Y would have been a better long-term solution. Do you have time to clean up that 53 line function in your Android app? Can that unit test use a few more, obvious, edge cases? You and I both know the resounding answer is: "YES!"

Source de l’article sur DZone (Agile)

/0 Commentaires/par

Scrum and Technical Excellence

,

One of the most common critiques about Scrum that I’ve heard from smart software engineers is that "Scrum does not care about technical practices. Scrum is for wimps." I’ve also heard managers down the hallway say that "Scrum is for wreckless developers because its main concern is only about fast delivery." I’ve heard many business analysts and solution architects tell me that "Scrum is too fragile because it does not specify the documentation the team needs to write."

People often say these things because they could not find in the Scrum Guide that says what technical practices the Scrum team need to do. But just because the Scrum Guide does not explicitly mention any technical practices you need to do, it doesn’t mean you couldn’t or shouldn’t do any technical practices. In fact, professional Scrum teams will find that technical practices are required for the software to be sustained in the long run. This is what agility is all about, not just about being fast in the beginning but slow at the end because of technical debts.

Source de l’article sur DZone (Agile)

/0 Commentaires/par

Technical Debt and Supporting Prior Decisions

,

Recently, I was asked to attend a session at a large corporation. The room was filled with technology-based executives, development managers, and enterprise architects. Also in attendance were a few of my peers from 

Upon leaving this discussion, I found myself wondering just how many other corporations are facing this same dilemma.

Source de l’article sur DZone (Agile)

/0 Commentaires/par

What Technical Debt Is and How to Calculate It

,

In an ideal world, every project is finished on time, and within the estimated budget. Even better, the budget has allowed teams to develop additional features and test everything one more time before the release. In the real world, the development process can encounter several difficulties, and technical debt is among the most common issues the project may face. It is essential to understand what technical debt is, how to evaluate it and especially how to tackle it.

What Is Technical Debt?

Technical debt is the additional work needed to complete the software development. But this notion does not refer solely to the projects that are in development. This issue often follows the projects that have been production for some time. This may be anything, like some module written on legacy technology, that holds the project back from including a new functionality or influence overall software stability. In this particular case, technical debt can be calculated as the time or money needed for the refactoring of this module’s code or porting it to the new technology. But usually it is never that simple and the software system includes a number of drawbacks that can be included in the technical debt of the project.

Source de l’article sur DZone (Agile)

/0 Commentaires/par