7

Let me preface this by apologizing if this has been covered elsewhere, but I was unable to find sufficient information in my searching.

Background information

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.

The problem

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.

Improve this question
1
  • Jeez, I hope you have a position open there -- I want to work there SOOO bad! About as bad as I want to perform open heart surgery on myself. Commented Sep 15, 2011 at 18:35

5 Answers 5

Reset to default
6

Suggestions:

  1. pass the Joel test. That will take care of most of your issues (as a note -- passing does not mean you have to have everything checked, but if you have a score lower than, say, 80%, you should consider the test failed).
  2. If you don't think that you can accomplish #1, pass the Joel test anyway. Trust me, it is just better that way. (The second rule of fight club being a developer...)
  3. Completely reject the idea that you are "not a software company." Is your department building software? Then for all intensive porpoises intents and purposes, you should behave as if the product is the output application. No exceptions, no excuses -- if you are building software, then you are building software.
  4. The number of times when software development best practices are not the best idea are extremely rare. For example: Unit tests are best unless all your application is doing is printing "Hello world". Even then, you should have verified integration testing and QA.
  5. Read The Mythical Man Month. If you can get your boss to read it, get him to. If not, at least do him the favor of saying, "Hey, I just came across a really awesome book, let me tell you about it."

Some rules which I have found which should be immediately applied:

  1. No code goes into production which is not in version control. The build must be made from the centralized repository.
  2. No untested code in production. No exceptions. If you're thinking about making an exception, hit yourself. (Don't know about the rest of the world, but I have been really burned by this).
  3. Redundant knowledge is cheap. Redundant work is expensive -- make sure that there are at least two people who are at least reasonably up to date on a given project (the person working on it, and someone else. If using pair programming, then that should be sufficient). This way, if someone goes on vacation to Mount McKinley or some other far off location, there will be a way to cover until that person returns. (Or worse, calling someone on vacation (Calling someone on vacation, by the by, surefire way to annoy them)).
  4. No undocumented code -- all public methods must have at least one line describing what they do, even if it is felt that the name is "self-documenting".
  5. Any person who is currently working on code which should go into production, should be subject to code review. This is especially true for the people who believe that they do not need code review.
  6. Finally remember the acronyms which should be looked for in said code reviews: DRY, KISS, YAGNI, etc.

For your own sanity, remember PEBKAC, but don't tell others.

Improve this answer
2
  • That's a LOT of stuff to introduce into an org that has none of it. Having as your first item, "Pass the Joel Test", would be an unfathomable amount of change to introduce in such a place. Instead, he needs to take "baby steps" to move in the right direction. Commented Sep 15, 2011 at 18:41
  • The base question is What are some practices that application developers at a non-IT company follow? It might not seem practical to implement any of them, but they are still the right thing to do. Commented Sep 15, 2011 at 18:51
2

Suggestions

  • Change Architecture

From a maintenance standpoint web based solutions are much easier to manage because you control the code on the backend. You don't have to support multiple versions of an app, and you can more easily manage releases and distribute fixes. Again, that is all because you control the backend.

  • Pick your battles

You are a software company because you make software. That being said, you may need to pick your battles when it comes to process change. Make a few changes, document the benefits that they yield, and then propose more. Too much change at the same time(even if it's all for the better) can be disastrous and may make the company less willing to change. Gradual change is much easier to accept, especially if you build up a track record of successes.

  • The basics

Revision control system, bug tracking (I suggest Redmine), these are the absolute basics for development. These should be easy to push through because it's about organizing and protecting the companies assets.

  • Get buy in from your fellow developers

Your doomed to failure unless you get your fellow developers to buy in to changing your process.

  • Later on

Automated tests, continuous integration, database usage, consolidation of functionality into libraries, etc.

Improve this answer
1
  • +1 amen. Buy-in is absolutely critical. The kinds of transition the OP is thinking of CAN TAKE YEARS. Example: it once took me 6 months to convince a team I was working on to use version control. Commented Sep 15, 2011 at 18:46
2

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.

I'd be tempted to want to have a few different documents to handle this:

  • End state - What are the things you'd like to see being used that aren't right now. This is where you get to have whatever grand dreams you'd want of the state at the end of the rainbow.

  • Transition plans - Prioritize the list of which practices in terms of which are likely to yield the best changes and write out a plan to bring these in slowly over a long time period. This is kind of like the road map to get to that end state and is a separate document because it is where you may have some fights in terms of how to get this done.

  • Hazards of current state - This is where you explain why the transitions should be done to get out of the current chaotic mess you have now.

Improve this answer
1

It appears you know pretty well what the issues are, the problem is getting solutions accepted. The processes that you have found for software development for an IT company apply to anyone trying to write good software. The software can't tell if you are an IT company (if it can - you're definitely an IT company).

Ask if the current process is producing the results they want - if they are OK with having analysis reports that may or may not be accurate custom produced from scratch every time with no ability to support them or reuse the code or the data for future requests, then your current "process" (or nearly any process) is fine.

If any of these things are considered problems, then doing the things you have to do fix them is by definition not overkill.

Improve this answer
1
  • Great answer -- you hit on most of the points I was going to mention. Commented Sep 15, 2011 at 1:51
0

Going with the "choose your battles" notion...

The biggest bang for your buck/effort would be a version control system. Talk it up, get people on your side, then convince management to provide a week-long training workshop for developers on how to use the tool. If you can pull this off, you'll be able to create a modicum of order in chaos.

If you're still working there when it finally gets used, you can then tackle introducing databases and the other stuff. But honestly, I think that if you want to develop as a software engineer that environment will slow you down.

Do some good, help them out, but use it as a stepping stone into a better job.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.