Today I want to talk about two things that I think are frequently done badly in the software development life-cycle. They are requirements gathering and deployment to production. These are both related to the end users of your software.
Developing software is a complex business and in the end, that software is designed to be used. In modern corporate bureaucracies, developers are frequently writing software for people who they’ll never meet and do not necessarily understand. That is a risk. It means that developers may write software that is difficult to use or that does not actually solve the user’s problem.
End users want software that solves problems for them. They also want customer service who are responsive when things go wrong, because they know that things will go wrong. This dictates that we must first find out what the end user’s problems are (requirements gathering) so that we can solve them, and then when we do start shipping software (deploying) we must do so in a way that means we can respond quickly to feedback i.e. we need not just deployment but continuous deployment.
Requirements
The first rule of requirements gathering is nobody talks about requirements gathering…
The second rule of requirements gathering is that a lot of people who develop software don’t talk to end users. That hurts your design. If you manage to design software that satisfies the experts who understand the problem domain but not the end users, your software will not be used. It’s really that simple.
The absolute most important rule is this:
Talk to experts for understanding of the problem domain, but talk to end users for detailed requirements. Experts are good at big picture stuff, but they’re typically not the people who are going to work with your software every day. They are not the end user, and without end user input you risk building software that is theoretically good but impractical for real life situations.
As we’ve already mentioned several times requirements gathering should not be a once off event that happens and then is over, it should happen continuously as the software is developed. For that to happen software has to be deployed continuously so that you can get feedback from end users. It must not be deployed continuously to a dev or test environment, it must be sent to production. To PRODUCTION. TO PRODUCTION. There can be no feedback loop without this.
Understand the existing solution if there is one
Going back to the start of the requirements gathering process, how do end users currently solve the problem that you are going to write software to solve? They might be doing this in several ways:
- There could be a manual solution.
- There could be an existing software solution.
- The problem might be ignored or they might not even see it as a problem.
Humans are resistant to change. They want to do things the old way. Unless the new way is demonstrably better and makes their life easier they will not adopt it. You need to understand both what the pain points are that your software will solve as well as the barriers to entry that will prevent it from being used.
I personally think that developers should actually spend some time working with end users and learning how to do things with the current system, or at least talking to them. It sounds extreme but a thorough understanding of the problem is the only real way to design a good solution, and a shortcut to that understanding is to experience the pain of end users first hand.
- What is good about the current solution? For example a paper based order system might seem clunky but for many paper based systems:
- The system is easy to understand and use. (New users are up to speed quickly and don’t need specialized knowledge).
- It is automatically durable – there’s a risk of losing records in a fire or other accident, but there’s no intrinsic problem with retrieving records from 20 years ago. ivermectin coronavirus 2021 A lot of modern software systems simply cannot match this.
- You’re not locked in to using a particular vendor of a particular software system.
- What problems are solved by the current system? It is not guaranteed that your software will encompass everything that the current system does. This can be a major barrier to the adoption of your software.
- Why would they want to change from the current solution?
- Do they need to do new things that the current system cannot handle? For example a paper based order system indexed by company name might not be easy to search for which company made a particular order.
- Maybe the volume of work is going up and the software will enable them to do it faster and more reliably?
- Maybe the current system has major problems which make it unfit for purpose? This could be the case if the current system was not actually designed for the purpose which it is now being used.
- The current system could be too expensive.
- There could be other problems, like that the current system is no longer being supported by the vendor.
- Your new system might, just might, have a KILLER feature that means they really want it.
You should also pay attention to general questions about the system like: What is the load on the system likely to be? compre ivenox How many users? How many transactions per day? Are these numbers expected to be static or to increase? Think about how your software might change the game that’s being played. These things all feed into your design and getting them wrong is costly.
More questions: how will your end users expect to use your software?
- Is it going to be used by single users?
- Will there be collaboration requirements?
- Are users going to be all in the same room or scattered across different locations?
- Are users organized into teams of some kind? Will that organizational structure need to be reflected in the software?
Keep an eye out for weird looking requirements that might need to be more general. For example a project I worked on had a requirement that a “maker” made changes and a “checker” approved them. para que sirve la ivermectina gotas 0.6 Initial requirements were that any user could be a maker or a checker, but could not sign off their own work. Later they wanted to change it that certain people were only allowed to be a maker or a checker, and they also wanted strange scenarios where multiple sign-offs were required, not just a single one, although they wanted to support single-sign-off too. Retrofitting the new more general requirements once a lot of code was already written was difficult and expensive. If you catch this kind of thing early and design for it you’ll save many valuable swearwords.
In my opinion developers should be the ones doing requirements gathering, or at least people with a strong technical background. People who’re non-technical tend to come up with strange requirements in the name of “helping” the developers, because they have some mental model of how the software should work internally so they subconsciously report their requirements in relation to that. It’s subconscious so it’s more or less impossible to eliminate. The more layers of analysts and management you have between the developers and the end users of the project, the more absurd the requirements that eventually filter through to your team, and the less they correspond to reality.
Try to avoid writing software at all
One rule of software development is not to reinvent the wheel. Although we are software developers, your primary purpose is to solve problems. And you may be able to solve the problem without writing a single line of code. At the very least once you understand the requirements it’s a good idea to investigate whether there’s an existing solution that can be used.
If there is an existing solution then it may not be fit for purpose, but if it is, you’ve just saved a lot of money and development time. Don’t ignore this possibility. Developing software carries significant risks, avoiding them all is good business sense.
That said, third party software solutions are not by any means guaranteed to be a silver bullet either, so they will need to be thoroughly researched before adopting them.
Even if there’s not something that exactly suits your purpose, exploring software that’s in the same space can still give you some significant benefits. You might find a useful library or some clever ideas which you can then incorporate into the solution that you do eventually build. Again, avoiding reinventing the wheel saves money and time.
Deploy to Production
One thing that the Agile movement pushes hard, and which is really good practice, is getting the software into the hands of end users as fast as possible. That means you have to get a deployment pipeline going that’s as short as possible. While you shouldn’t expect end users to act as testers, you should also not be too rigid about protocol to get stuff to them.
Things to know:
- A lot of people talk about Minimum Viable Product – the smallest, most basic product that you can hustle together in the shortest time, that will solve someone’s problem and people will want to use. This can be surprisingly basic. It can be buggy (ideally not too buggy). It can be missing major features. ONE useful thing, that’s all it has to do. It can be embarrassing to look at. It can be slow. Get it out there. Get it to end users.
- You should sell it, if that is an option (i.e. you’re developing software for sale and not internal stuff). Don’t be too quick to jump on offering people freebies in exchange for beta testing or something like that. Once you have something functional sell it. It’s important to get a revenue stream up and running. Also selling a customer software obligates you to satisfy that customer. It will make you more motivated. Also customers like to pay for something as that is a guarantee that they can chase you if your software goes boom. If they’re just part of your beta programme they feel nervous because if your software breaks something mission critical for them they have no recourse. Ideally try to make software that doesn’t break.
- Don’t set internal milestones and pretend that they’re minimum viable product. MVP is only MVP once it’s actually released – preferably sold – to end users, and not just beta testers either. Real end users.
- Don’t stress too much about bugs. Obviously you will have to fix them, especially if they’re major ones, but customers can be surprisingly tolerant of bugs. Use that to your advantage. As long as you can tell customers “It’s a known bug and we’re working on it” they’ll be OK. If you tell them there’s a work around they’ll be chuffed. If you tell them it’s fixed in the next release then they’ll be ecstatic but a. make sure it really is fixed, b. make sure the next release is available now! NOW!!!!! Also, make sure that production bugs are fixed as fast as possible. They take priority over pretty much all other development. Customers need to trust you and for that to happen you must be responsive to their concerns. A public bug database like many open source projects have is not a bad idea, but may be a hard sell to management.
Once your product is in the hands of end users, make sure to listen to their feedback. Part of the point of getting your software to them early and often is that you want that feedback. You are looking for
- Bug reports
- Feature requests
- Comments on useability
- Comments on how people use your software. People are creative. They will do things with your software that you never thought of. They will use it for absurd things and send you bug reports when it doesn’t do as expected. You can then decide whether to support that absurd scenario or not.
Deployment Mistakes
It’s easy to fall into a couple of traps with all of this stuff.
- We must only deploy well tested software that has passed multiple reviews and is signed off by the Grand Poobah. And thusly shall you deploy once or twice a year, and when you do go through the heroic struggle to do so your end users will immediately find bugs or stuff that you didn’t think of because your requirements are out of date or wrong and they’ll wait another six months for fixes by which time they’ve wandered off to read YouTube comment threads or whatever end users do when they’re not using your software.
- We must only do internal deployments of this fantastically complex software until the big reveal!!! Then we’ll show all our competitors! They’ll be gob smacked. Their flabber will be ghasted! … And just like the previous case, your end users will be all like “Oh, it doesn’t do X that I want. It is complex. Oh, you can’t change it because it’s internally complex yet doesn’t suit my needs. Hello competitor with less fancy, cheaper, faster deployed software that can be modified to suit me. Yes I’d like six gajillion orders please.”
