Effective software development, delivery, and support
Guest post by A. Cranky, Old Man
tl;dr – I’m using Visual Paradigm.
When I needed a way to create a reasonably good-looking sequence diagram for a recent engagement, I was suprised to discover more than 80 diagramming tools on the market. Given such a large pool of candidates, I expected to find several good ones, and I embarked on my quest in hight spirits.
You’d think at my age I would know better.
Continue reading My personal quest for a UML diagramming toolA recent toot on Mastodon reminded me of a phenomenon I believe is pretty common these days: An unusual event causes us to reconsider our habits and assumptions in some way.
The toot was this one from Benji Weber, posted on February 9, 2023:
The blog post he references is here: I Was Saved By Test Driven Development.
The toot and blog post explain what happened clearly enough; there’s no need to reiterate the details.
The angle I’d like to bring out is the pattern: We operate in domain X in a certain way based on our established habits and our assumptions about the best way to do X. Then something unexpected and/or unusual happens that causes our habitual way of doing X to be uncomfortable, clumsy, expensive, or unworkable. At that point we reconsider our habits and assumptions, and possibly change the way we do X.
I stumbled across an article about COBOL dating from 2020, and I thought it might be useful to clarify a few points. The article is What Is COBOL and Why Is It in Demand? by Jennifer Seaton, published on the Make Use Of site.
In the 1971 movie THX 1138, George Lucas’ first feature film, the title character gets in trouble with the law when he gets his girlfriend, LUH 3417, pregnant. In the highly regimented society in which they live, relationships like theirs are illegal. The authorities throw him in jail and redesignate LUH 3417 so he can’t find her again.
THX 1138, along with a couple of other escapees from jail, look for a way out of the subterranean complex where their society lives. Ultimately, THX 1138 is the last of the escapees still at large. The robot cops try to convince him to return with them, but he refuses. When the pursuit exceeds 6% of the budget allocation for chasing escapees, they let him go and he reaches the surface.
The question you may be asking is, “What does that have to do with anything?”
Updated 6 Nov 22
Thousands of thoughtful and experienced software professionals use Twitter to share information and interact with one another. We’ve come to depend on Twitter as a source of information and interaction with colleagues.
With the recent changes at Twitter, many users are looking for alternative social media platforms. But many of us hesitate to “leave” Twitter because that’s where we find industry leaders in the software field, and we don’t want to miss out on what they have to teach us.
Continue reading Where to Find Prominent Voices in Software Other Than Twitter
Way back in October, 2022, Florin Pop tweeted this question:
He got 400 responses in 10 hours. Some were lighthearted: “I would use HTML.” Others went into some detail about a favorite webapp development stack. I came to the party late, but I thought it would be a fun thing to try.
If you understand how these things relate to software development work, then you require no training or coaching.
Handling stress and working with others requires self-awareness and emotional control. All the skills listed here also require self-awareness and emotional control.
It is widely agreed that software development teams are either improving mindfully, or they are deteriorating in their effectiveness. There is no steady state. To make improvement possible, team members must be open to learning new things and willing to question things they already know.
To achieve anything, you must focus on it. That means uninterrupted time to think and work. It means finishing one thing before starting another. It means not getting distracted. It means keeping your eyes on the goal and not on dwelling on the difficulties.
Overcoming challenges and meeting objectives requires persistence. Embracing change to improve our work requires persistence.
In almost all cases, software development work benefits from collaboration between two or more people. “The more you share, the more your bowl will be plentiful.” – James S.A. Corey, The Expanse.
Effective collaboration requires trust and the courage to be seen as vulnerable or imperfect.
Leadership doesn’t mean giving orders. It means giving credit, giving time, giving space, giving encouragement, giving opportunity, giving trust. The more you give, the more you get.
A steady, predictable, consistent, and sustainable pace of work helps ensure continuous flow, maximize delivery effectiveness, and minimize team stress.
The field of software is constantly changing. Software architecture, design patterns, programming paradigms, methods and schools of testing, of analysis, and other areas, design principles, development practices, automation, operations, and everything else is a moving target. To get started in this field, you need basic education/training in analysis, programming, and testing, and the non-technical skills listed above so that you will have the ability to keep yourself current with technical advances and to collaborate with and learn from your colleagues.
Without the basic training, you will have no foundation to build on. It would be like trying to run a foot race on top of loose ice floes on water. The general discussion of what skills are necessary tends to emphasize the non-technical side of things; don’t take that to mean there are short-cuts on the technical side. The reason for the emphasis is that the non-technical skills have been underappreciated in the past. On the other hand, don’t worry if you feel as if there’s too much to learn. Once you have the basics, you can build on that knowledge little by little.
Here’s a story.
A development team was thrashing as they attempted to use Scrum to help them build a new application. They had numerous defects, some of which escaped to production and others that were caught within each Sprint. Many defects they thought they had fixed popped up again in production.
Their stakeholders had high expectations, as the team’s velocity was high. After several Sprints, it became clear they were not going to deliver all the planned features by the defined deadline. The news came as a surprise to stakeholders.
I’ve noticed in many business meetings, and especially presentations, people use highly stilted, quasi-academic language. They may have useful things to say, and a pleasant, cultured voice to say them with, but the language leads me to wonder why people think they have to sound academic at work, and whether they would speak that way normally in any other context.
I mean, if they think it makes them sound smart at work, wouldn’t they want to sound smart all the time? Who wouldn’t, right?
Continue reading What if people always spoke the way they do at work?
There’s an odd situation in the software industry. Employers are adamant that they can’t find suitable talent to fill the technical jobs they have. Job candidates are adamant that they can’t find suitable work. It seems strange to me that both these things are true at the same time.
Many people have opinions and observations about this. Often, they cite academic studies, industry surveys, formal management models, psychology, and various other things that are confusing for a Bear of Very Little Brain like me. I wonder if we could go a long way toward solving this problem if we ajusted, just slightly, the way we think about what we’re aiming to accomplish, on the hiring side and on the job search side.