Let me preface this by apologizing if this has been covered elsewhere, but I was unable to find sufficient information in my searching.
I work at a non-software company developing desktop applications in a team of four members, where I have been employed for more than 18 months. Being my first job out of college, I was unsure what kind of development environment to expect. What I found was transition of applications developed in a legacy language being rewritten in an OO language.
On our development, we have no guidance, practices, etc for how we plan (if any planning is done at all), code, and deploy our applications. As you can imagine, such a policy (or lack there-of) has bred pure chaos for managing applications, with often times each developer creating his/her own way of handling situations. In other words, LOTS of repetition. I have come to understand why I am the third new hire they have had in three years (other two left after one year).
Allow me to list off other issues:
- No unit testing. The only type of "testing" that is done is handing it over to the user and asking if this is what they wanted. Half the time the user doesn't have time to check it and just starts using it to produce their analysis data.
- No database. We have several, several thousands of records and information that are stored over a multitude of CSV files.
- No documentation. This speaks for itself. No user requirements. No explanation for how to make the program work. Nothing.
- No bug tracking at all.
- No version control.
- Overwhelming number of applications. We have well over 150+ small applications. Many of which no one knows what they even do or how they work. The development policy is each time the user needs a new report, create a brand new program with just one button. Push they button and magically on a network share in a folder, several reports in notepad are created.
- And many more issues...
So... what are you asking us?
Ah, now we get to the real reason for all of this. I have been tasked by my manager to propose suggestions and guidelines for our development team. Mind you, I am not optimistic that anyone will actually heed them, but I have to propose them none-the-less. Most of the suggestions I have found are for software companies. I have been informed by other people at my company that such practices would be "overkill" at our work.
What are some practices that application developers at a non-IT company follow?
Thank you for your time.