What I Do
I was reading Ben's blog and decided to take part in the ongoing discussion of describing what you do for a living.
I think what I do is best described by the rare combination of talent and interest in a subject that most people find rather boring, overly complicated, too meticulous, or something so abstract they can't fully comprehend it. If you haven't figured it out, the subject is software development and computer system architecture design.
Here's a typical conversation I have when meeting someone and the conversation winds through what a person does:
Person: So, what do you do?
Me: I am a consultant.
Person: So, what do you do?
Me: I am a software developer and application architect.
Person: So, what do you do?
Me: Like right now? I am building a deal capture and data integration system that allows 2 other trading software products to work together for a power trading company.
Person: Cool. Well, I hate computers. I can't even get my mail to work. Speaking of, do you know anything about Windows??? I am getting this weird error message when I..............
So to the average person, I work with computers.
That being said, what I do is solve problems and implement ideas. Whether the ideas are related to the actual business, such as generating invoices, or they are related to internal processes, such as streamlining team development practices, what I do is try and solve the primary question on the minds of all management: How is this going to make more money? What kind of return on investment will I receive for this undertaking? How can I make the business more efficient?
More and more, I am engaged into projects more related to articulating and managing risk, which might not necessarily give an exact and measurable ROI, but is necessary to prevent losses. For example, cumulative open positions are used by trading companies show the current risk with the company. This is a number that is required for many different reasons and is quite necessary both internally for management but also for external credit management. So basically, the computation might not give you a specific and measurable ROI, but it allows the company to reduce risk.
So what do I do? I make those calculations faster. I make those calculations wider and deeper. I show those results in a format allowing for better communication. I also provide more insight into how those calculations could be seamlessly integrated into other decision making processes. How do I do that? By listening. Listen to what my customer wants, provide feedback and alternatives not only solve the question at hand but leverage the work across the entire business, and then ultimately doing what they want and need.
I create answers to questions. My answers just happen to involve computers. That's what I do.
Importance of Testing and Refactoring
Here is a great article on the importance of testing, centered around using JUnit.
http://clarkware.com/articles/JUnitPrimer.html
From the article....
"JUnit tests allow you to write code faster while increasing quality.
Yeah, I know, it sounds counter-intuitive, but it's true! When you write tests using JUnit, you'll spend less time debugging, and you'll have confidence that changes to your code actually work. This confidence allows you to get more aggressive about refactoring code and adding new features."
The main risk from refactoring is always the dreaded regression testing. Regression testing scares users so much because of potential for hours and hours of work they spent clicking and dragging and moving data in different ways to be nullified. I have witnessed several legacy projects in my career in which ingenuity and creativeness were strangled by irrational fears of regression testing.
Software should be built to always fulfill the interfaces designed, but allowing for switching of implementations based on need. Business needs should drive software, and improperly designed software or lack of proper testing should not hinder the development team's productivity.
Bogged down with older technology? Legacy application giving you fits? Try starting with building a comprehensive test suite to manage regression testing. Show the users how easy it is to double check system functionality. Get their buy-in. Then when you want to improve a process or change an implementation, they won't start shaking as bad.
Red Flags for Project Managers
"We don't need code reviews"
Everyone benefits from code reviews. The junior developers benefit from code reviews by being exposed to new code and new ideas. The senior developers benefit from code reviews because it allows them to mentor junior developers and at the same time refine their processes for development. Managers should LOVE code reviews because it allows the team to become more efficient, leveraging others work and streamlining repeatable development issues via application of patterns. Managers should also love code reviews because it exposes the weak links. No longer will the individual developer be able to just turn in their code, have it work and not have the work scrutinized. In my opinion, a majority of the headaches dealing with "legacy code" could be averted with simple checks and periodic code reviews by management. If any developer does not want to do a code review, you can imagine why.
"It won't help performance, so why bother refactoring?"
Performance is very important. Performance is required. Performance is not the ultimate litmus test and should be handled as a single, very important aspect of software development. Think about it this way, if performance was the ultimate benchmark, then we would all be writing in assembly language on a mainframe. Like it or not, good coding is just as important to a project and refactoring is a major part of what makes a project successful - in the long term. When approaching a subject to refactor, there should be several things in the mind of the developer. First, will this change affect performance? Secondly, will this change be so great as to require massive regression testing? Thirdly, will this change greatly increase the chances of saving the next developer time and effort in coding a module? So if you can refactor something that doesn't necessarily improve system performance, doesn't require massive regression testing (which shouldn't be a big deal if you have your automated testing and build process set up) and will save the next developer(s) that require/touch this module time, why not? Performance is great but should not be the only concern.
"I really don't care what other developers are doing."
Have you ever walked into a new project and started looking at the codebase only to realize developers have been getting database connectivity three different ways? What about 3 different sets of constants files? Or perhaps you changes a factory to return an new implementation of an existing interface only to have regression testing fail because a colleague decided they would just new some DAOs or Services? I mean, who needs a factory when all the factory does is say new Object()? Every developer should care what the other team members are doing because there is a good chance you will end up maintaining that other developers code when they win the lottery or get eaten by sharks.
"I don't have time to refactor anything."
Chicken and the egg. You don't have time to refactor because you are too busy forking through a huge pile of spaghetti. But if you would refactor badly written code, you wouldn't have to wade through the piles of garbage, thus saving you time and giving you the opportunity to refactor more badly written code. The question is: Would you take an 8 hour hit NOW if it would save you 40 hours over the next month? If you can't afford the time to do it right, how are you going to find the time to fix it later?