When you open the jar you will know much more of what to expect than just the amount of beads, but “how many beads?” was the only question needed to start the conversation.
Estimates in software is not about scheduling tasks or defining velocity. “How big is this task?” is a shortcut to a discussion on scope, technical limitations and prerequisites.
We need to understand our options when prioritizing. The scope might be interpreted in different ways. Members of the team have relevant knowledge unique to them that changes the understanding of work required. All of this will show in an estimate of size.
Instead of taking all the beads out of the jar to sort them, we just ask how many they are. Then we keep the information it generates and throw out the estimate.
]]>The previous post is on coping with IT-stress This is about preventing it.
Software is named in contrast to hardware. Computer programs should be easy to change. You can get an update into production in less then an hour, with modern methods. ( Refer to Accelerate if you encounter someone who says otherwise.) If the software is not working, for the ones using it, the software should be changed.
Half of corporate budgets for software (in Sweden) is used for customisation. Either for modifications of existing software by external parties or external developers working on in-house projects. On top of that, about 40% of IT-workers in Sweden work for companies that produce something else than software.
That is a lot of software being written with a specific customer in mind. If you are that customer, demand to be a part of the entire process. Software tailored to your needs requires your input, just as a suit or dress is made with multiple fittings.
“Off the shelf”-software has to be tried by the end users before committed to. The cognitive ergonomics when investing in software should be considered similar to ergonomics when furnishing a workshop or office.
If the software is a part of your “competitive edge”, consider having a dedicated team of software developers, who get to know you and your domain really well. Provide them with direct access to the end user and put them close to (or in) the product team.
The software team should be like a painters brush, swift in the hands of product development.
If your software team can not deliver on that, provide them with training and other support until they do. Your organisation deserves it.
The purpose of software is to make things better. It is a failure if the end user can not easily use the product. We can check that we are building the right thing as we go, if we have the end user close and work in small steps. In Extreme Programing, a flavour of agile, the customer is represented in the team. If that does not work, find another way to get constant and real feedback. This avoids delivering something that is “done”, but can not be used.
Whenever you can, demand more of software you encounter. Accelerate is a good book on what can be expected of an organisation delivering software. The DevOps report 2021 and The DevOps report 2019 are shorter reports covering the findings from the research. Remember that soft in software is soft as in changeable. If you are in charge of spending money on software, off-the-shelf or in developer hours, take your responsibility. Software development is best done with the end user in focus and in small steps. Don’t accept less.
]]>It is not your fault.
Software causes stress in the workplace.
The stress can come from things breaking down unexpectedly, like projectors not starting, audio missing in the video conference call or the e-mail draft disappearing as you refill your coffee.
There are also the thousand cuts from the paper free work place. Interfaces that are clunky, dropdowns with a thousand options, where the most common is the last. Forms demanding you to type in the same information three times and then complains about the format. (Perhaps by erasing everything you entered in so far.) Information portals with unreliable search and no predictable structure. Not to get stared on permissions to add or change information (or structure).
This text is about coping with what you can not change. Part two is about eliminating the source of the stress (bad software).
Software should never make you feel stupid.
When the printer throws a tantrum or an app suddenly restarts, the responsible people are:
Unless you are on that list, it is not your fault.
Software doesn’t have to be like that. The industry knows how to create intuitive interfaces. There are processes for writing reliable software. User research exists, just not enough. You deserve better software. No human is non-technical, it is the technology that is inhumane.
Reporting issues with software has two benefits. If the software organisation is good, it will use the feedback. For organisations too immature to appreciate it, at least you can use it to let out some steam. Put your frustration into precisely worded descriptions and screen recordings showing the problem. Be polite, since that will help the organisations who welcome it and annoy those who don’t.
If the workbench has the wrong height, or the knives are blunt, you can not expect the best results. The same is true with IT. You have to adjust the expectations on your staff accordingly. (At least until you are able to fix the software.)
The cognitively ergonomics of a workplace are as important as the physical ergonomics. Software that is hard to use and/or unreliable, will affect the work, regardless of the attitude among the employees. It is biology.
Software developers also suffer from IT-related stress. No one is too clever to benefit from easy to use software. If you are taxed by flaky tests or buggy editors, know that you also deserve good interfaces and reliable experiences. You are not less for wanting to work smart rather than hard. If you struggle with getting software to work, it has nothing to do with your aptitude as a developer. You don’t have to be smart to make someone else feel stupid.
If you are a manger, or a role model, in IT, don’t idealise fire fighting. Acknowledge when infrastructure and tooling are slowing you down, and celebrate the canaries in the team.
]]>early-career people should take the time to download and look at the leaked farcry code. not to learn some new technical lessons, but to disabuse themselves of the notion of “clean code”. nicebyte
From reading more of the thread, my interpretation is: “You don’t need good programming practises to make money from software.” That might be true, in some circumstances, but to make it an “early-career”-advice I would like to add some perspective.
First I want to separate internal and external software quality, as described in this post. Internal quality is from a developer perspective, external quality is what the user sees. They can be more or less dependent of each other, but have different effects.
J.B. Rainsberger has a talk on “The economics of software design” (video). There he introduces t0, the point in time where the total cost of having written the code is the same regardless of if we just did it fast and sloppy or slower and intentionally sustainable. We don’t know when t0 will be, but it exists for every project. After t0 you reap the profit from having continuously improved the code since the start. In just implementing features as fast as possible, we bet against the project surviving past t0. We only save money by not caring about “clean code” if the project does not reach t0. The t0 measure is about the value of internal quality.
It is interesting to use a game as an example for when internal quality is unnecessary. Games are one of the few kinds of software still distributed on physical media. I believe that a lot of games change less over time then other software. The cost of a messy codebase come when we want to edit it. Bugfixes in a feature complete codebase can be plastered on, as long as the code do not move.
In my post on useworthiness I talk about how utility and usability mix to decide if software is worth using. If we can not add new features utility will suffer. Usability will be a problem if the internal quality problems show as external quality problems, or slow down improvements in user experience over all.
For games that change more over time, like Pokémon Go, the condition of the codebase matters, and will start to show. Niantic has publicly stated that they have quality problems. In Pokémon Go the problems shows as defects, delayed features and draining of the users resources such as mobile data and battery. All of that results in lower external quality.
The gamble here is both with t0, “will the project die before the codebase does?”, and with the users tolerance for unreliability, in relationship to how the game makes money.
Pokemon Go makes money, but Niantic has still recently laid off 25% of its workforce.
This is why my “early-career” advice is:
Find work where they care about code quality.
It will be better for your mental health as well, but that is for another post.
]]>On the other hand, a badly designed, or even unstable, product that provides something really valuable, will be used anyway. (That is, until something better is available, or the pain grows too big.)
Useworthiness is the combination of usability and utility. How well it works is weighted with how valuable the function is. Both impact how the user interacts with your product.
Compare it with food. That something is easy to eat and that it is tasty is two different things. Eating canned corn with a spoon is really easy. Despite that, I prefer to eat it fresh on the cob, including the flossing required afterwards.
If you work with software that provides something really useful, people might be using it despite its level of quality.
If it is something that the user has to do, participation data is even less valuable to decide the quality of your product.
Get feedback from you user, besides recorded data, to separate the usability from the utility and retain customers over time.
If you take pride in producing quality user experience and product stability, make sure you work with something valuable to people, so that it is not wasted.
User research is the best way to get useworthy products.
]]>
- Communication overhead
- Risk of conflicting interests
- Temporal dependencies and scheduling problems
(Interruptions from auditing, or bugs found by external quality assurance, is a version of temporal dependencies.)
This consumes resources that could’ve created value.
As soon as the software organization grows enough for the developers to split into more than one team, the dependencies will change. In the worst case both teams depend on everything the old team depended on, and each other. Managing dependencies more important in bigger companies (due to math). Kent Beck has a great text on what you can do to deal with dependencies from within an existing team. The suggestions below require more influence over the organization. The goal is to create working software with as few dependencies as possible for each team, while maintaining a reasonable team size. The book Team Topologies covers much more on how to organize teams, so I include their names for different teams along my own.
This is done in DevOps. When running the code is included in the responsibilities for the team, operations is no longer a stakeholder. The same can be done with product, security and user experience. This is one of the reasons to have the customer be part of the team in XP. A cross functional team gathers all expertise in one place. The main focus is solving the business problem as well as possible. This improves all three listed problems with dependencies, since collaboration is moved to within the team.
Organize teams around their goal (user path or feature) instead of what technology they use. This also requires cross functional teams. It is easier for the code to adhere to the single responsibility principle when the team has only one goal. In Team Topologies the “Stream aligned team” is clearly intent centered. “Subsystem teams” and “platform teams” can also fit the description, if the other teams are seen as their customers. Solving the scheduling aspect of the dependencies relies on that the stream aligned teams can move forward independently of the subsystem and platform teams. (Platform teams are very different from a backend team, that still has to implement changes for each feature in the frontend.)
One way to see it is that the business logic is created by stream aligned teams. The technical advantage can be created as a subsystem or platform, used to improve the work of other teams as it gets available.
If the overhead from having specialists in each team gets too big, you can have service teams. In Team topologies those are “Enabling teams”. This flips the direction of dependency between teams. If the legal team is there to control, it is a stakeholder for the software team. On the other hand, if the software teams take full responsibility for the legality of their code, the legal team can be there to serve them. The legal team then has the software teams as their stakeholder. It can still create delays, but the control and the responsibility is with the development team. Legal advice is pulled from the legal team instead of pushed to the development team. This can be used for other areas as well. Service teams still have to manage their time, but they should at least not have to explain why their work is needed. So the conflict in interests is solved.
The core in universal design is to move away from the able bodied user as a norm. People with disabilities are not a new kind of user, they are a part of the general user. We design for different screen sizes, without having stories like “as an iPad user I want to be able to buy a ticket”. The same way we can simply make accessibility a part of how we work. This is easier with a diverse team. Universal design can also be expanded to include other marginalized groups. I don’t think that “as an African American I want to be able to use face recognition” should (need to) be its own story. It is what we want to achieve that differentiates users, not the circumstances we are (currently) in.
Read my posts on working in an ensemble! This deals with all the listed problems with dependencies, but between individuals within the team.
]]>I believe that software developers are a lot like octopuses. To thrive, we need problems to solve, or we will create new problems, and in some cases, problems for others.
Most software development can be done quite simply today. We have high level languages, frameworks and libraries for technical advanced things that used to be done by each team. Now the work consists of using existing tools to express the domain and adapt them for the product. Most software today is developed where the programming part does not require you to be very clever. (In a proper, modern, environment. Unless you are doing something totally new, most are not. I am not even going into AI.)
Implementing a solution, screen by screen, or api-call by api-call, that someone else designed, is not enough of a puzzle.
So, what options are there for a developer who loves problems?
My suggestion is that programmers should be a part of product development. Give software developers business problems to solve, as part of a team. Then we can safely aim to make our codebase easy to work with, even boring, because we know that we will never run out of problems to solve. The cognitive ability will be put to use where it is most needed, to solve hard technical problems when they arise, and to support the business at all time. And that is only one of the benefits!
]]>Not only will anti-work make life harder inside the organisation, it also leaks into the surrounding world. Anti-work pollution!
There is a lot of literature on the topic targeting the IT-industry. The Phoenix Project both describes where it comes from, and parts of what we can do about it. Preventing anti-work is also something a Technical Coach helps with.
We want to minimise anti-work to be more profitable and a better work place. We should also pay attention to what our anti-work does to people outside the company. An organisation that fails to prevent anti-work for its employee, will also cause anti-work for its customer.
It might not be that the entire system is down. It is enough that there is some kind of unavailability or error, that will ask more of the customer than they planned for. Restarting apps or devices. Forms that clear all entries on a single error. Data that don’t sync properly. Having to wait or reschedule your task for another time. And it is not only software that manifests it, though it is often software involved. (Or better software could have prevented it.)
Ordered food that only partly show up might not seem like a biggie, but it might also cause the anti-work that blows up something really important for that individual at that time.
When the anti-work hits your life, instead of your work, we often lack protective systems. The nuclear-family team of two, or one, doesn’t have the redundancy of an IT-department. If the service you build is of any use, or importance at all, it hurts when it fails the user. It might only be a paper cut, but could be one of thousands in total. It will probably hit harder for people with less privilege to start with. As a system, a society, we should all be more careful with each others time and energy.
Don’t be an anti-work polluter! Take care to build quality software!
]]>Then the focus is moved to connecting with the child.
“What part of this chapter did you like the most? What do you think will happen?” Most of the time the request is actually about connecting with the parent.
Next time I get a feature request, that will not be instantly prioritised, I will try the same.
“Yes, it would be nice to also be able to filter days by phase of the moon . If it would not have caused any other tradeoffs we would implement it today, but it is not possible at the time.” Then move on to connecting and getting the customers perspective. “What problem would filtering on moon phase solve for you? What made you come up with that idea?” It might be that this customer has insights that you can not get from your perspective (some live their lives by the rhythm of the moon). It can also be that the customer likes your service and wants to be a part of the work, feel connected and seen. By both asking about the feature and taking interest in the customer the questions move from justifying the request to understanding the customer.
So next time a customer scream for ice cream, see it as an opportunity to connect.
Ps. One such parenting book is this “Med känlsa för barns självkänsla”.
]]>In the analogy with a factory our groomed backlog items can be seen as work in process. Throughput in a system is limited by high work in process. Backlog items do not take up floor space. But they can get old and irrelevant, or stress the team by being a metaphorical mountain of waiting work. The buffer before a machine is calculated by using the throughput and the time to replenish. Therefore I suggest that the meetings for grooming the backlog should be scheduled in proportion to the team velocity and the current size of groomed items. A rule of thumb is
time to next meeting = work in groomed backlog / (velocity * 2)
This is not precise, so you do not have to measure velocity, just get it about right.
Going through backlog items is hard cognitive work, and we are not very good at doing this for long periods of time. So having shorter, more frequent meetings, will help us stay fresh and focused. Pick a time in the morning, when the brains are fresh, or after lunch and some rest where the brains have gotten new energy. Then keep it short, preferable under one hour, and focus. That way you will make better decisions and stay engaged.
We get better at things that we do often. Things that are painful, but important are good things to get better at. Hence, do painful things more frequent. For Toyota this was setup for the machines. For me it is time reporting. For some software teams it is grooming the backlog. Do a short retrospective after each meeting and focus on the improvement of the processes. Then we will get really good at preparing our work, and well prepared work is more fun to complete.
]]>They go to the quality assurance team that tests finished products. There they find a lot of things that passed through a bottleneck, but got discarded. since they had shortages in quality. By moving parts of the QA before the bottleneck, they save the limiting station from working on things that are already broken.
What is the equivalent to this in software?
I do TDD and BDD! you might say. If we assume that the developers are the bottleneck I would say that it is rather like making sure that the products are not broken during or after they are at the bottleneck.
My suggestion is that we see user research and design sprints as our way to make sure that we do not have products that are already broken taking up valuable time at the bottlenecks. Every feature, that is not tested against a real user, risk being waste in process instead of work in progress already when it reaches the development team.
The best way to increase the capacity of a bottleneck is to find what it should not do. By doing design sprints and user research you can try a lot of ideas that do not have to go though the full development cycle. (It has other advantages too.) By investing in usability and design a lot of redo and undo can be saved.
Make sure that all tasks that get turned into code has first been checked that they actually should be implemented. That is how user research limits waste in process.
]]>