The need of at least one state of the art project

  I want to talk to one of my current employers about the need of having, at least one state of the art project, keeping in mind that this company have some very bad projects, bad when you think about the archtecture, bad in usability, bad when you think about code's elegance.

  I would love some opinions, as although he's a great guy and open to ideas, he have been bombed several times with ridiculous requests, or false promises of efficency or quality. I will have one shot for that, i guess, and I want a headshot.

  Anything that would support me in a discussion.

  As I am finding more evidences, i will post here. Please if you do have an opinion, or an experience, I would be more than glad to use it, when i'm facing the guy, trying to help t开发者_开发百科his company out.

Thanks.

Looks like you are trying to improve the software development project in your company. You don't need a "state of the art" project to do it. If you are a developer approach your boss showing evidence of the bad things you can find on the software, and explain them how these bad things affects quality, efficiency, time and money spending... and then suggest concrete measures that can be taken without much effort to improve those aspects.

The better way to teach your boss about the benefits of good code and development process is to put in practice a better way of doing things when you are in a concrete project, and then show him how this approach is an improvement over another projects.

I suggest you reading Joel's advices in the article "Getting Things Done When You're Only a Grunt"

If your employer is experiencing severe software development problems, a new 'state of the art' project is the last thing you need. Read up on good software development practises and put them to use in a small project first. Pragmatic Programmers is a good place to start for reading material.

Perhaps instead of asking for ideas for a project, you could talk about a few issues your business has, and ask if anyone has ideas on how to deal with them in a way that would demonstrate your ideals to your boss.

I don't understand why you feel you need to have a "state of the art" project. I'm not sure I even understand what that means. What if none of the "state of the art" technologies or methodologies fit your business needs?

My advice is to:

1. Find a problem to solve. Unless your job is to come up with new things and then create a need for them - then, congrats on your cool job and I'll shut up.
2. Solve it well - use the methods and technologies that solve the problem in the most simple, efficient, cost-effective, timely, and maintainable manner.
3. Profit. Your boss should understand more than anything that YOU understand his business and care about its success, not just some noble ideals about improving software development for humankind.

"State of the art" is what you make it to be. I do understand where you are coming from, however. I was in a position similar to you with a previous employer. I would be willing to bet that there are a few things that you can do to bridge the gap.

1. Start refactoring. A green-field approach is seldom attractive to those who sign the checks, unless there is an organization effort to do so. As a developer/architect, it can be very frustrating to work in a "legacy" codebase. Identify the contention points and what the better way would be to address the problem. Write unit tests to ensure that any changes are non-breaking. It may be a good idea to use something like a proxy pattern to isolate the new code from the old code. Delegation through such a class will let you structure the new code how you see fit. Take the opportunity to create a new assembly that houses application architecture functionalities. If you plan it right, you can start using this application architecture to refactor other parts of the codebase in a fairly non-invasive fashion.
2. Solicit feedback. If you do not like the code, chances are - the rest of the team will have his/her issues, as well. Find out what parts of the code they absolutely dread and why. Chances are different people will dislike different areas and provide insight that no one person is going to provide. Create a clear action plan, and figure out how it could have been done better. This will give you an idea of what direction to take.
3. Code reviews. If you aren't doing them, you need to start. Correct issues in the code going forward so that the team does not continually add to the heartache. It also provides a good opportunity to say, "We put something in place to make this easier. Look at how you could do this with the new application architecture..."
4. Educate. No matter how cutting-edge and clean and pristine something might be, under deadlines, people will revert to however it can be done quickest. Make sure to provide opportunity for refactoring and communicate better ways to accomplish things.
5. Adopt better tooling. Things like ReSharper are priceless and can generally be argued to the powers that be about the productivity gains. Not to go down a ReSharper rat hole, but look at the plugin for StyleCop, and the ones called Agent Johnson and Agent Smith. Reach out to the interwebs and find good starting points for things you are trying to accomplish. Codeplex is a treasure trove of projects to make any architect's life easier.
6. Don't give up. It is really easy to get frustrated. Stick to your guns, but don't be a tyrant about things.

I followed a very similar approach to this, and it works. Eventually you build up a solid framework to build off of, and new projects start by being built with it. It becomes second nature to use, and the developers will enjoy refactoring code to make things more concise, stable, and "cutting-edge".