Introduction
Work life balance
This issue is mostly commentary on things I found around the web. Picking up the theme from “ Working on the Weekends - an Academic Necessity?” I'm OK with that: I haven't spent as much time blogging and recording in the last two weeks and that means the time must have gone elsewhere.
Next weekend there'll be a new issue of De Programmatica Ipsum, on requirements. In my experience software teams struggle way more with negotiating what to build than with any technical issues related to actually building it, so I hope this issue will be a useful contribution.
Writing
On the locations of the bullet holes on bombers that land successfully
I made the main point I wanted to make in the post: saying “big company X works this way/uses this thing therefore you should too” is not a good argument, because it only tells you their outcome (and not whether the outcome was due to or in spite of choices made). But I'll expand here.
I find it fascinating, having lived through the first wave of Agile adoption, that Agile is now the "boo heavyweight process encumbering teams" word. Back in 2007 when my management were rejecting calls from the engineers at the digital coal face to adopt an Agile approach to software development, it was the “less ceremonial bullshit, more focusing on outcomes” word.
Maybe it's not that I'm surprised that there are still ways to improve engineering processes, with the Agile manifesto being written in a continuous tense: “We are uncovering better ways of developing software…”. I'm surprised that the rejection of Agile software development as values, principles, and practices is total, when it seems to be based on a dislike of some of the practices.
Actually the principles and values are still there: Kocienda says “A clear vision. Design-led development. Weekly demos to deciders who always made the call on what to do next. Clear communication between cross functional teams. Honest feedback. Managing risk as a function of the rate of actual progress toward goals.” That sounds like working software is the primary measure of progress, like customer interaction is valued over contract negotiation, like continuous attention to technical excellence and good design. Maybe the post-Agile way of working is the agile way of working after all.
On self-taught coders
People who describe themselves as “self-taught” usually actually learned from somewhere, so I ask the two questions: where did they learn from, and given that they learned from there why do they instead say that they are self-taught.
Around the web
Complex software makes economic sense
Why did nobody go back to refactor that codebase? Because it wasn’t worth doing. Or at least, it didn’t seem worth doing. Estimating the future value of today’s software is even harder than estimating the cost of change, and many developers do neither.
The SPACE of Developer Productivity
There is more to “productivity” in software engineering than the number of code changes per unit time—managers who focus on that often find it grinds to a halt over time as people get dissatisfied and code gets harder to work with (see the previous article).
Here, the authors put forward a holistic framework for thinking about productivity on a software team. Notice that some of the dimensions are contradictory: both collaboration and individual efficiency are important.
The Software Industry Is Still the Problem
I’m generally in favour of calls like this for increased liability for poorly-constructed software: and without the “but not for me as I only write small apps/websites/medical devices” exclusions people like to carve out for themselves.
I also don’t worry about how we grandfather in existing practitioners, because we don’t. I look forward to more programmers wanting to learn how to become software engineers.
For a more detailed call for liability in computing, check out the book Geekonomics: the real cost of insecure software.
Working on the Weekends - an Academic Necessity?
Overwork doesn't just apply to academia, indeed I have seen many software engineers in the commercial sector who put in long hours on their main jobs and then have side hustles or learning projects in the after hours.
I'm not immune—I'm doing a research doctorate alongside a day job—but I am disciplined. The doctorate gets a couple of hours of my time in the morning. The day job gets the working day. The rest of my time is my own. All that you win by having side projects is the opportunity to do more side projects: your employer has no need to reduce your workload or give you development time if you're going to do all of the work and development outside of hours.
And join a union, so you can push back collectively and join coordinated, democratic campaigns about these issues. In the UK, software engineers can join United Tech and Allied Workers and there may be sector-specific unions with bargaining agreements, such as the Universities and Colleges Union in academia. For other countries, check and join your local unions.