6

I joined a software development company around a year ago. There are a couple of teams working on different products, however, there are a number of common libraries that all teams have to use. My team actually maintains a specific library that one of the other teams integrates into their product.

The overall problem is that there are no well-defined processes of maintaining software inside the company. Most of the common libraries are poorly documented, people are removing code rather than deprecating it (which breaks code that depends on the libraries), and there are no changelogs in place. The policy is that the projects should update to the newest library versions ASAP, however there can be multiple updates during a single day, or a single update can easily take half a day.

I'm not a member of the company's senior staff, however I have some experience in software maintenance and OSS, and I am thinking about bringing up this topic with my manager in hope that he could escalate it further. I strongly believe that good processes will improve the quality of software we build and will help reduce unnecessary stress between the teams. Should I do that? Is there anything I should consider when preparing for the conversation with my manager? Are there any ways my initiative can backfire?

Improve this question
2
  • 1
    Sounds to me like your company needs a change manager. Perhaps you're available for the position? Absolutely, bring it up. With perhaps a draft of a job description that would constitute a solution. Especially if you'd like to be the one to fix it. :)
    – BobRodes
    Commented Apr 5, 2016 at 7:52
  • Can you get buy-in from any members of your team? Testing the waters there would be the most logical place to start. Making organization wide changes are fraught with politics. You'll have a much better chance of succeeding in your effort if you can show how "your suggestions" have helped your team improve productivity, decrease bug rates or some other measurable concrete numbers to support your case. Most software people won't understand your assessment, so do you think someone with the power to make an organizational change will understand? You need numbers. They will understand numbers.
    – Dunk
    Commented Apr 6, 2016 at 19:50

3 Answers 3

Reset to default
11

Anything can backfire. But your approach is the right one. I mean documenting what is being done at the company and providing/maintaining backwards compatibility are all good things. The only thing I can suggest you is to start slowly and in a very tactful manner. Your boss or a close friend of his might be the maintainer of that code base, or might have written it at one time in the past, with no regard for maintenance and it was liming along all the way. Now a newcomer, "hot shot yuppie" in their eyes is trying to teach them how to do their jobs. If this is the case, it will not be taken lightly. Even though they will know it is the right way of doing it, they will resist and put one obstacle after another, trying to explain, what you said should not be done.

But in most well structured software companies, your suggesting will sound like music to management's ears. But in that case, be prepared to take the lead maintainer role, which will be a big time sink, while paving the way to upper levels in the corporate ladder, if you do a good job.

Improve this answer
3
  • 1
    If the company is small and lacks the hierarchy of some bigger companies: I'd recommend going in with some strategies that have the potential to work instead of just being that guy who knows something is wrong but intends on doling out the work of fixing it elsewhere.
    – CKM
    Commented Apr 5, 2016 at 0:44
  • 1
    The advice I'd add to this good answer is that you should present your advice in the form of real problems suffered (e.g. examples of other teams' code breaking due to library code removal) and proposed solutions. Definitely agree that you should be tactful and do so in a non-judgemental way. Far too often I see programmers who can't describe an existing problem without making it very clear that they think the problem exists because everyone other than themselves is an incompetent halfwit. Don't be like that.
    – Carson63000
    Commented Apr 5, 2016 at 1:48
  • 1
    I think if you can get someone from one of the teams who will be feeling the pain of all these bad processes. Sit down with them and work out if you really are solving the problems for them or understanding the problems and then that's a great information point. 'Bob' on the application team told me they've wasted X days this month on these issues. I think being able to speak to the pain in real terms may carry more weight with some managers than it being purely on a holistic process level
    – PatrickWalker
    Commented Apr 5, 2016 at 7:53
4

Many of the problems you discuss are signifcant weaknesses in change management and / or the SDLC process.

No well defined processes for maintaining software within company

  1. How do you track what changes have been made to the software,
    especially in the production environment, if one exists at your
    company?

  2. Given no change logs are used, how will you trace a change made and determine whether the change is authorized and not malicious?

  3. How do you trace changes to the users that made them, because if you can't do so, no one person can be held accountable if a changes breaks critical functionality.

  4. People remove code rather than deprecating old code. This is a very bad practice as you suggest. What happens if a release fails and has to be rolled back? Without old working code to revert to, there is the risk of business disruption due to inability to recover from a failure / disaster.

What does the SDLC process, whether this be WaterFall or a version of Agile, say about how code changes are processed? Is there a QA function that enforces proper development techniques?

Pay attention to how related processes at your company are working.. Given how slipshod change management is at your company, I am willing to bet heavily that related processes are no better. Some questions worth thinking about, assuming your company is mature:

  1. What are the job roles of employees that have the ability to modify / remove code from repository?
  2. Are incompatible duties segregated such developers having direct access to production?
  3. Is testing and documentation of results required before deploying code to production?
  4. How reliable are the rollback / restore procedures in case a change made were to crash the system?

You should also recognize that if your company is a public traded company in the United States stock market, it is subject to Section 404 of the Sarbanes Oxley Act - SOX, if the process under question affects financial reporting in any manner. Sarbanes Oxley - Section 404 mandates management bear personal responsibility over the adequacy of internal controls in their company. Top management can go and have had gone to jail if convicted of fraudulently mis-reporting on internal controls.

I work in IT Audit and my job is exactly to bring issues you mention in your post to the attention of management for resolution. My suggestion is for you to discuss with your manager that current processes present signifcant risks to the the company in terms of business disruption, system integrity, and client satisfaction. If that fails, raise the issue with the Internal Audit function at your company, if such a function exists at you company, and you are authorized to speak inter - departmentally.

In summary, if after your presentation to management, and still no improvements are made, you probably should think about finding another job as this development environment is detrimental to your growth.

Improve this answer
1

I strongly believe that good processes will improve the quality of software we build and will help reduce unnecessary stress between the teams. Should I do that? Is there anything I should consider when preparing for the conversation with my manager? Are there any ways my initiative can backfire?

Look at what you yourself wrote about your employer:

There are no well-defined processes of maintaining software ...
People are removing code rather than deprecating it ...
There are no changelogs in place ...
Projects should update to the newest library versions ASAP ...
There can be multiple updates during a single day ...

This isn't just cowboy programming; even cowboys follow rules. This is open range bandit programming, where there are no stinkin' rules, no stinkin' processes, no stinkin' configuration management, no stinkin' version control. Nothin' but slingin' the code. This is an organization filled with people who don't need no stinkin' badges.

A software development organization that in 2016 does not bother to use even the most basic of version control systems does not want processes. Period. People who end up working for such organizations do so for a reason. They don't want to be bothered with any of that "process stuff", even if it would help them.

So yes, there are many ways your initiative can backfire.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .