The impacts of not documenting your software

The impacts of not documenting your software

Here I am again talking about software documentation.


If you are still skeptical about the need for documenting your software product, I have some news for you.


My activism on behalf of software documentation and FOSS communities isn’t new. However, right now, all that I have been preaching about when it comes to documenting software came to be true.


Last month I got a call from a Brazilian company. They are desperate to get someone to organize their documentation and create a successful process flow for their company.

It turns out that I have been saying to people from this same company how they are lacking the proper care when it comes to documenting their product. Now, that they got to sign with an international company, they are desperate because said company won’t accept software that has no documentation.


Funny thing is, I have been predicting this situation for quite a while now. So here I go again. The best advice that I can give your company/startup is document, document, and document. So when you get the chance to sign an international contract, people won’t look down on your project.
Yes, the documentation process tells a lot about a company and how it deals with Software Quality, software assurance, and problems.


It’s evident that if you don’t document your failures and problems, then you got a big chance to repeat the same errors over and over. Does your company have a high rotativity of employees? And you haven’t think about creating legacy documentation? Well, guess who is going to spend much more time to train an employee? Yes, it’s you.


Big opportunities won’t embrace your idea if you can’t show the minimum respect for software documentation, and technical writing. It’s as important as your software running. Believe me, when the opportunity comes you don’t want to be caught by surprise and with just 2 months to organize your whole process and document it.


Do it right, from the beginning and you will see that the benefits are much better than the time you “spend” doing the boring documentation task.
This is about creating a whole organizational culture over documenting processes, mistakes, workflows, features. If you create this kind of mindset, then your company will be much more organized and grow a lot more.

Because writing helps us to identify great enhancements, problems, and even opportunities. It helps employees to understand better a project, to keep everyone on the same page.

The Brazilian software scenery has a lot to learn especially when it comes to preparing to do business with foreign companies.


The great advice here is to help you with keeping a budget when contracting someone to care for your documentation. If you already have workflows designed and organized, software partially documented, then this person won’t cost you a lot. Just enough money to organize your documentation process and get things on tracks. But if you have a mess and expect someone to solve it, then expect them to charge you accordingly.

Copy?
Over.

Software Documentation: Chiming About The Brazilian Scenery

Software Documentation: Chiming About The Brazilian Scenery

As a software documentation writer, I have been struggling since I decided to focus on that forgotten part of software development: documentation. Brazil is a country that is having a software development bloom for a couple of years now. We had an increase in software companies, digital solutions, and other I.T. related ones. However, the software documentation grows ever so slow.


The awareness for concise and clear documentation, be it for the final user or even to make the software maintenance understandable to new collaborators, is almost null. This reflects directly at the number of positions available for technical writers, software business analysts, and many more that deal with software documentation.


Following some Brazilian software developers closely, I began to see a pattern of companies hiring programmers and overwhelming them with all the processes related to software delivery. This isn’t a generalization, we do have some companies that are down to earth and understand the different roles making a good software product. However, it isn’t uncommon to have a front-end being responsible for writing legacy documentation of the software product or even instructional documentation aimed towards the users.


There’s no need to say that it doesn’t work well. A front-end developer has to study and develop front-end applications, worry about the design and user experience, about integration with the back-end, and so on. If we force those professionals to assume two different roles they will not exceed in either. Brazilian companies are still seeing software documentation as something unimportant, thus not giving enough importance to this role.


The international market has been improving daily, seeing how projects with strong documentation can lead to fewer mistakes and build a better experience for the users. We all learned about good practices to develop, and documenting your software is one of them. Worldwide and among international companies, we have been seeing how software documentation has been improving their workflow and, is taken seriously. They are recognizing the need and the benefits of hiring a professional to deal with it.


I hope that Brazilian companies understand how important it is to have good documentation, not only for their users but also to aid new members and help with software maintenance. Until there I follow advocating for respect to each professional and recognition for their value as a collaborator. A programmer isn’t supposed to do everything in your company.


Copy?
Over.