Current go-to methodologies when developing software are agile-based (e.g., scrum). Work is done in increments between one and six weeks called sprints. At the end of the increment, it’s expected to have part of the software ready, which can be showcased and receive feedback.
Depending on the feedback, either the next part of the software will be developed during the next sprint, or the chunk done in the last sprint will be reworked.
The main idea is that short feedback loops reduce the risk of failure. The less time lost, the better. By doing the work one specific subsystem at a time, any changes, enhancements, and reworks can be done while the development team is concentrated on that specific part of the software.
And yet software projects are consistently delayed and delivered with defects. In this third part of our series, we’ll take a look at the reasons behind development problems, as well as the strategies and tools necessary to address these issues.
Software Development Problems
Although developers usually try their best and have only the best intentions for a project, most software projects are delayed, and there are always bugs shipped in production.
Why does this happen, and what makes software development so hard?
Naturally, there is no single answer, but from my experience with both enterprise and startup projects, there are a few recurring issues.
Firstly, requirements tend to change on the fly. Writing code that does something specific is easy; experienced developers can even predict and avoid most bugs.
However, requirements usually aren’t clear. They are abstract; they lack details and use cases.
In an ideal world, the developer can ask about the uncertainties and get clear, concise answers instantly. In reality, however, this is never the case.
Most of the time, people can’t give a clear answer or aren’t authorized to make decisions. Furthermore, some specific user stories may require several meetings to be decided upon. Still, a decent developer can abstract the parts of the code that aren’t clear to make it more flexible, since at the end of the sprint, they must showcase something ready.
Abstracting the code, however, comes at a price: It is less concrete and some bugs will be missed.
Right off the bat, the optimal code can’t be written due to these uncertain requirements. To make matters worse, requirements tend to change several times before release.
Developers hate this, and for good reason: They must throw away code and rewrite it. The code they are writing must allow the change to happen easily, since they won’t be given enough time to implement it from scratch.
In defense of the business, changes to the requirements are made after testing reveals they aren’t optimal or, even worse, they don’t achieve the desired effect at all.
For example, it can turn out that a certain payment method isn’t popular among the target audience of the software, so a new integration must be made.
Naturally, this isn’t the only problem. All too often, new features are added on the go. Once again, they are presented as crucial for the success of the product, but the timeline remains the same.
Due to lack of time, all too often, these issues are rushed, with poor quality and many bugs, yet these features end up getting released because they are required by the business.
Does this mean that developers are being sabotaged by the business? Are the delays and bugs in the software strictly due to changing requirements and adding more things in the same time frame?
No.
Initially, years ago, it was very hard for me to acknowledge this, but the truth is people (read: everyone) can’t estimate tasks. To make matters worse, developers often aren’t prepared enough to take on a project.
Why is that? Aren’t developers supposed to know how to build software? Isn’t modern software development, to a large extent, gluing different systems and services together? Why is it so hard?
Why precise estimation is nearly impossible is handled very well here, so I will unpack on why developers have a hard time on some projects.
Most projects include technologies that the developers haven’t worked with. I am not talking about the programming language, operating system, and all that.
These technologies are expected to be known, and developers shouldn’t have problems with them. If the developer doesn’t know their tools and can’t use them well, chances are they’re not that great of a developer.
There are two main types of technologies where software developers meet hardships.
The first one is the integration with third-party software/services. Usually, there are specifics that aren’t documented, and the developer must find them and work around them on their own.
Although doing prior research and testing the service can reduce the time spent, usually there isn’t time to research the third-party services that will be used before the development cycle begins.
The second one is the core of the software—the part that is unique, that doesn’t exist and must be made from scratch. Usually, there are hidden complexities and edge cases that make it significantly harder to implement than initially expected.
Not every project will have a complicated core. Not every project will have third-party integrations. From my experience, projects that don’t have a complicated core, for example, WordPress sites and web stores, usually have a lot of integrations and plugins.
You may be asking yourself: How is software development such a mess? It’s far from what is advertised and what I imagined. Truth is, software development is messy in the real world. On paper and in isolated environments like college, it looks much easier than it actually is.
Still, there are certain steps that can be made to bring the chaos down a couple of notches.
The problems we have talked about so far are:
- Changing requirements
- Adding more work without adding more time and resources
- Being unfamiliar with third-party systems
- Dealing with the complex core of the software
Let’s group the problems into external (changing requirements and adding more requirements) and internal (familiarity with specialized software/services and tackling obscure and complex tasks).
Fighting the Problems
One common strategy is to overestimate. For example, let’s say that a project is estimated to take two months to complete. If you add two extra weeks, you will account for some of the changes.
You can get away with overestimating; however, it has to be with a reasonable amount, since if you want 50% more time, then most likely people won’t give you any extra time.
Another key thing is to be open with the delays. If something is taking more time than expected, don’t keep this to yourself. Tell the people involved. You may get some help, you may get some more time, and some less important features can be pushed back.
As far as new features are concerned, the most important thing is to be open about what is possible. Explain when something can’t be fit into a time frame. Ask if another feature can be deferred and finished after the initial release.
Even though many people will tell you that “everything is important,” it isn’t. Most things are just nice to have, and although they will enhance the software you are working on, they aren’t business-critical.
Adopting the Proper Mindset
The good news is that internal problems can be handled by the developer, by adopting a proper mindset:
Take responsibility for your mistakes. When you have underestimated something, do not lie. Admit your mistake and suggest a way it can be fixed, even if you have to delay the feature. The more you try to hide your mistakes, the more they will drag you down.
Speak the truth and don’t set unrealistic expectations. It is tempting to speak optimistically. Don’t do that, since it may end up hurting the company, forcing you into unwanted overtime. Keep things simple—don’t mislead anyone.
Don’t let ego get in the way. I can write an entire article on how ego ruins promising software projects. The best part is that I can use myself as an example. Always, always, always try to keep your goals in mind, and don’t try to prove anything to anyone. The quality of your work should speak about your skill, not you.
Ego is very hard to keep in check. I fail with this from time to time and it has yet to create a positive experience. Every time I let my ego loose, I make things worse and then I have to fix issues before we can continue working on the existing problems.
To make matters worse, ego is very common in software developers, so chances are when you speak up, you will get in a needless, destructive argument with someone. Don’t let ego get in your way. Don’t create another problem.
Don’t jeopardize your work as a professional due to pressure—your responsibility as a developer is to produce high-quality, maintainable code. You must not sacrifice that, as tempting as it will be, since it will create technical debt, which will cause future enhancements to the software to be delayed and will make debugging and maintaining the software harder.
So far, we have discussed the top problems that modern developers face, and some of their solutions. We have also discussed the mindset that needs to be adopted.
The important part we’ll now address is the strategies and tools a modern developer needs.
Strategies for the Modern Developer
Adopting the right habits and setting the right intentions in a top-down view will help you be more focused. When you are more focused, you will be able to flow better. The better you flow, the more value you add.
Having a time structure helps everyone. Unfortunately, we live in an era where distractions are all around us. You can structure your time to check your notifications only every 30 minutes or so.
The Pomodoro Technique is the go-to time-structuring strategy for software developers.
In a gist, you split your time into intervals in which you work without any distractions, say 25 minutes. After that, you get a short break, usually five minutes, and every four pomodori, you get a longer, 30-minute break. The idea is that you break up your task into small, manageable chunks and see progress quickly. If you go in the wrong direction, you won’t waste more than 30 minutes. It has been proven to work, and many people praise it as a productivity saver.
I use it at work most days when I don’t have any planned meetings, and it works wonders. I am not using it every day, since sometimes due to meetings spread out through the day, it adds an unneeded layer of structure.
Tackle the high-risk tasks first. One of the downsides of programming is that you have to wait quite a bit before you see the results of your work, which pushes a lot of developers to do the quick tasks first.
This is counterproductive. This isn’t a high school test; the high-risk tasks aren’t just a part of the project, they are the part that, if it fails, will fail the entire project. You can’t skip them and just get a B instead of an A in software development—it’s all or nothing.
You don’t have to finish these parts to 100%, but you should be sure that they will work and do most of the work to validate that they won’t be a showstopper.
This means that a decent percentage of the time may pass without you having to show anything 100% done. Although this may be demotivating, trust me, it is much more demotivating to have to explain to the team why the last few weeks of combined effort go down the drain because the high-risk tasks are impossible to complete at this time.
Make sure feedback is received. If you are uncertain if something is good or bad, ask for feedback. If you are certain, ask regardless! It is astounding how many bugs can be caught if someone else has a quick look at the code.
Don’t forget that although you write most of your code alone, you have colleagues for a reason—to help each other. A few minutes of code review from a colleague who hasn’t seen the code before can save hours of debugging.
Try to reduce the time wasted in meetings. My best suggestion here is to only attend meetings where you can actively add value. A lot of the meetings are between two or three people who each drag a few people with them for support more than anything else. If you can’t actively contribute, you might as well skip it.
Tools for the Modern Developer
As far as the hardware is concerned, use whatever suits your particular needs and is in budget. The most overlooked asset is ergonomics. Just keep in mind that you will stay at the workstation for a lot of hours. Make sure it is comfortable and it won’t cause you any pain.
Also, think about your eyes—maybe buy glasses or pick a monitor with built-in protection. Noise-canceling headphones are also worth considering.
I’ve written a lot about text editors, but that isn’t the only thing you need to configure and keep in mind. Code linter, style checker, basically anything that will make you deliver higher quality work should be used.
The things you’ve set up must be automated. For example, run all code-related checkers when you commit and reject the commit if any of them fail. That way, you won’t forget any check and you won’t be able to submit work with subpar quality. If the checkers aren’t automated, you will skip some of them and they will be a burden, not help.
When it comes to supporting software, use whatever feels right for you. It is important to make sure that the software you are using is actively supported. It is also important to know what data it stores, if any, and where it is stored. Although I use primarily open-source software, I do occasionally buy commercial software.
Try to use only software you need. If you want a graphical client for your version-control system, get only one. Don’t get multiple software products, since you won’t learn any of them properly.
When you choose a tool, make sure it is configurable. You should, in time, make it suit your personal needs and your personal workflow.
This should cover the important tools. Feel free to add stuff as you need it, but just remember: Too many tools will slow you down and will distract you instead of helping you deliver quality code, fast.
Trust the Process
With the right mindset, tools, and strategy, the only thing left is to trust the process. Like any endeavor, there will be ups and downs. Some days will be good, some days will be bad.
It is important to trust the process, to press on when you meet hardships and not to give up.
Software is complicated, and it takes many years to master, but if you start applying the strategies and mindset I’ve shared with you in this article, you will start seeing a positive change very soon.
Published on Java Code Geeks with permission by Zlatin Stanimirovv, partner at our JCG program. See the original article here: The Modern Developer, Part 3: Development Opinions expressed by Java Code Geeks contributors are their own. |
