DEV Community: Zigi

Dev's life - its time to reduce the noise

Zivit Katz — Thu, 16 Dec 2021 10:30:35 +0000

Developers are the most valuable asset to any organization, and time and productivity are the most valuable assets to developers.

The cognitive overload that developers are facing is eating into these assets, and it’s hidden in the small moments, constantly, throughout the day.

Zigi’s here to change that!
Join Zigi’s beta today and be a part of our mission to #reducethenoise.

👉 https://www.zigi.ai/

Dealing with software development waste

Zivit Katz — Wed, 15 Dec 2021 11:01:53 +0000

This article first appeared @zigi' blog

Written by Shanika Wickramasinghe, Senior Software Engineer, Sri Lanka.

Nowadays, software development is becoming ever more complex by the minute. To meet the requirements of the rapidly evolving technological and business landscape software development life cycles have become complex operations consisting of different processes, systems, and all development teams. All to combat this complexity. However, this increased complexity has introduced waste into the software development process.

This in turn has developed teams constantly stretched to meet deadlines while managing the product expectations of customers, management, and end-users. Also, this increased complexity has put delivery teams under constant pressure with continuous development cycles. Thus, they have to perform as effectively as possible since even a small delay can cause a cascading effect that affects the complete development pipeline.

Here, in this article, I am going to explain different types of software development waste I have experienced while doing my job and I will further suggest how to deal with them effectively.

Types of Software Development Waste

Unnecessary Meetings

Daily standup and weekly catchup meetings are the norms in many organizations. Besides, properly managed meetings are vital for managing the workload, knowledge sharing, and dealing with blockers in the development pipeline.

As a developer, the most important asset for me is my time and unorganized or longer meetings are the most common time-wasting factors. Another pain point is getting invited to unnecessary meetings just to listen to other people talk with the subject matter having no impact on me or my work. For example, if there is a product demonstration, the best people to demonstrate the functionality is the relevant developer or the team and not the whole delivery team.

When you are in a code sprint, you are focused and you can easily tackle complexities in your solution. However, this focus is constantly interrupted if you are constantly invited to meetings, especially when they are spread throughout the day day. You will not be able to block a consistent time to focus on your coding.

For regular and necessary meetings I believe that the best way to deal with this is talking with your managers and colleagues before a meeting to get to know the exact agenda so that you can assess the importance of attendance, provide your input and leave early if possible or simply outright decline if possible.

Relearning

As developers, we are constantly learning new things. This can range from learning new technologies, ways to fix issues, introduce new features, etc… All these things ultimately help to improve the final product. However, one major misstep done by us is forgetting how we came to a solution or what we learned.

Assume that you figured out a solution to a blocker yet forgot the steps to overcome that blocker. Then you will have to research and relearn everything from the beginning leading to wasted time in the relearning process.

The only way to overcome this issue is through documentation. Any solution, fix, or workaround must be well-documented regardless of the severity of the issue. You might never need it, yet the documentation of a solution can become a lifesaver whenever it is needed. Keeping documentation does not mean that you have to create professional documentation. I use a note-taking app to keep my findings and as needed create more comprehensive documentation.

Inefficient Switching and Hand-off of tasks

We always have to deal with different tasks, even when you are in a code sprint if there is a production bug you will have to switch to fixing that bug. This is a necessary evil as it is not feasible to work on a single task continuously. Yet, it all comes down to how effectively we transition to a new task or handing over current work to a different team member.

This shifting focus undoubtedly leads to development waste as it will take some time for you to get accustomed to the new task. If you are constantly changing tasks this can add up to hours of wasted time. Also when handing off tasks you must ensure the other team member is up to date with the current process and have the necessary skill set to tackle the task successfully.

When a bug fix is assigned to me, I immediately try to involve the developer who is familiar with the product or, better yet the developer who initially developed the feature that is causing a bug. This can cut down the acclamation time by half as you can quickly drill down to the source without having to learn the underlying logic from scratch. Tasks should always be assigned to appropriate personnel. A python developer should not be tackling PHP issues or a DevOps engineer specialized in AWS should not be diagnosing a GCP issue.

I always keep a track of where I left off in the previous task before switching to a new task so that I can quickly switch back. Additionally, when handing off tasks make sure that appropriate team members are assigned for tasks. If a senior developer manages the current task, it will be more effective to hand it off to another senior developer than assign two junior developers.

Complex Solutions and Feature Creep

Software development is a complex process where most scenarios require complex solutions to obtain the desired functionality. However, it is essential to keep the development as simple as possible as complex solutions require more time and resources to develop and test. This leads to software development waste if simple solutions are available.

Always try to adhere to the KISS model (keep it simple, stupid) and most of the time the simplest solution is the best solution. As a developer, your first instinct would be to program something but this is not always the best approach. A 30-minute google search might reveal a pre-existing solution savings hours of wasted development time.

When developing you may think that you can improve functionality or simply make the solution more elegant by developing beyond the scope of the requirement. Unless you are assigned a task to improve a feature or functionality, never try to improve perfectly functional functionality. If you do this and an issue arises, you are just adding unnecessary work to yourself and may even cause a conflict with the original developer.

What I do to keep everything within the assigned scope is to clearly define the goal of the requirements before starting the development and If I need further clarification, I would contact the BA who is responsible. This takes any ambiguity out of the task and I can scope the requirement. Then put all my effort to create the best outcome within this scope.

Conclusion

Software development waste is an issue that negatively affects the development lifecycle at both organizational and individual levels. It causes waste of time and resources in organizations while making developers stressed and overworked, leading to poor performance and efficiency across the board. The best way to manage this is to identify types of software development waste and quickly address them to reduce the waste as much as possible.

Zigi, the developer’s asistant for non-coding tasks is open for beta.

Join our mission to eliminate wasted time & burnout for developers

What developers love to hate?

Zivit Katz — Wed, 01 Dec 2021 09:21:47 +0000

This article first appeared @zigi' blog

Written by Aleksander Kubista, Android Engineer, Poland.

Nowadays we are not moaning, nor are we complaining. You do not dislike, you just have different opinions. When we have doubts, we can talk in groups and resolve them. Afterwards we give strong feedback. We even invented special meetings for this, called retrospectives.Yet it appears as developers we are just human beings and sometimes we are far less sophisticated than we think. We let ourselves fall into primitive hating. Usually the reason for our annoyance is the same. In general we don’t like to waste time, especially when you have deadlines, you are stuck with code reviews and your new QA is constantly reporting some minor issues as blockers. So let this article be an anonymous manual called “How not to make your developer hate you”.

1. Bureaucracy and Interruptions

It is not easy to manage projects. To organise them, we tend to introduce more and more processes. But I know too many developers who claim they have less than 40% of day time for real coding. They waste it on meetings, F2F, surveys or reports. And the thing I hated the most: time reporting. Once my typical day started with a common standup, then a detailed meeting about my current epic and then some random call about an urgent bug. Of course between each call there was less than a 30 minutes gap. I spent 4 hours at work, did nothing but 3 meetings and was already too tired to code properly. I started to begin work as early as 6 am so there were no interrupts. We need frames, but a good manager must make sure that they don't become our chains.

2. Setting up Environments

Majority of applications have some specific features based on user profile, selected offer, filled forms etc. I can not count how many times I needed to ask what precise steps I have to take to reproduce some scenario. Then reproduce it several times during development, constantly not being sure if the fix works or the setup is wrong and servers respond with error. Afterwards you pass this hot potato to the rest of the team. Now when you multiply that by factors like experiments, feature flags, channels, app and API versions it might become a real pain. Even if you invest in a custom tool to generate the requested environment automatically, it might still be one of the least liked things during everyday routine.

3. Tasks Overload ‍

Our typical work day consists not only of coding. Our responsibilities often include performing code reviews, resolving reports, answering questions, reporting service outages, controlling our domain or checking on current rollout. To make our lives easier we created multiple tools. In the end we have a panel with metrics for this. Logs for that. Links to documentiations, pull requests, wireframes etc. Then you need to follow a calendar, chats, call and many more. It is just impossible to even remember everything yet make use of it. What we need is to reduce the clutter. Automatizations and integrations of even simplest tasks may benefit in less stress, smaller silos, better scalability, faster onboardings, and loads of saved time. ‍

4. Poor documentation

‍Working with legacy code is not easy, but it can become even more difficult when domain is so robust and old that even project managers don’t know its use cases. Almost every subtask begins with endless talks and research before you even start. As time is ticking you don’t make proper notes. Instead of one source of truth you end up with info scattered across chats, wikis, comments and your brain. Moreover no one cares that this part of the project is the place you should never visit. They need just “rough” estimations. When you try to explain that you might as well read the tea leaves, they will joke that you are the best and only you can do it. Naturally later they tend to treat it as deadlines. The only thing that you can do is to make sure you will be the hero who will save the next generations from this chaos.
‍

5. Miscommunication

‍Coding is just a small portion of work for your next feature. We depend on so many other people like designers, QAs, analysts, translators and others. Each of them has tons of hard, specialistic words and their own project slang. In such conditions It is too easy to understand something differently, which later turns into wasted time and grief. I would love to see more people who actually pay attention to how they describe their thoughts. Tasks should be written in such a manner that literally anyone in the corresponding position could understand them. In fact as time passes it is very likely you will forget context too. We should keep in mind that shortcuts taken now, will be our delay in future.

6. Lack of purpose

They should've warned me that one of the side effects of being a developer is the great need to see sense in what you do. There is nothing more frustrating than going through a task we find useless. That's why it is so important to explain what is the reason for this next feature and why it should be done for yesterday. In a world where coding is almost like magic, and you can create marvelous inventions, wasting time on some dull task without understanding the whole concept might be depressing. Especially when at the end of the process, the feature is cancelled or cut in half. Sounds impossible? We all know it happens a lot.

Conclusion

There is nothing wrong that our work environment is not ideal. The only problem is when we do not improve. So often we fall into the vicious circle of rushing to the next task, because we have no time as we were delayed with the previous task. Why? Of course we had trouble with legacy code, or we had to fix bugs which our tests did not cover. That is why recognising and fixing technical debt is crucial. And by debt I understand more than just poor code. It is also hidden in our processes, pipelines and tools. We all began our new work with passion and energy, but overtime if there is no sign of progress we get grumpy again. Yet there is a hope that after reducing our daily pain you might end up with a highly motivated and happy team.

How do you feel??

Developers say goodbey to non-coding tasks

Zivit Katz — Tue, 30 Nov 2021 17:11:00 +0000

> Hello world (and all you developers out there)👋👋

𝐀𝐫𝐞 𝐲𝐨𝐮 𝐬𝐢𝐜𝐤 𝐨𝐟 𝐥𝐨𝐬𝐢𝐧𝐠 𝐭𝐢𝐦𝐞 𝐭𝐨 𝐧𝐨𝐧-𝐜𝐨𝐝𝐢𝐧𝐠 𝐭𝐚𝐬𝐤𝐬?
Are you tired of the constant noise around mundane tasks, endless systems, and complex processes that keep you from doing the work you love?

𝐒𝐨 𝐚𝐫𝐞 𝐰𝐞

Meet Zigi, your own AI-powered personal assistant that manages your entire dev workflow and handles all your mundane, non-programming tasks across multiple apps, so you can focus on code creation and innovation. 😎

𝐖𝐞’𝐫𝐞 𝐡𝐞𝐫𝐞 𝐭𝐨 𝐫𝐞𝐝𝐮𝐜𝐞 𝐭𝐡𝐞 𝐧𝐨𝐢𝐬𝐞 𝐟𝐨𝐫 𝐲𝐨𝐮 - 𝐣𝐨𝐢𝐧 𝐨𝐮𝐫 𝐛𝐞𝐭𝐚 𝐠𝐫𝐨𝐮𝐩 𝐭𝐨𝐝𝐚𝐲 𝐚𝐧𝐝 𝐡𝐞𝐥𝐩 𝐮𝐬 𝐬𝐡𝐚𝐩𝐞 𝐙𝐢𝐠𝐢!

https://www.zigi.ai/

** Zigi currently supports developers that are working with: Slack, Jira, Github, Bit bucket (with more on the way).