This past summer I was employed as an intern for a high profile software company. I must admit I was afraid that I would be unprepared for the real world of Software Engineering. These fears came from many articles I have read in the past, some of which were linked in a previous post here. Basically, I was worried that I didn't feel like I knew anything about unit testing, scrum teams, agile software dev, and many other software development tools/practices that should be taught in schools and aren't.
The one tool/practice I did know about was version control. In my junior year of college I took an advanced game design class where I lead a team of programmers and artists to make a game. Version control was of paramount importance for the success of our team. We used a subversion repository with branches and very regular check ins. You checked your code in the moment you were done working on it and checked it out the moment you started working. If there were conflicts you merged them as well as you could.
Now I felt like I was quite successful in my internship this past summer. I was mostly working on a simple tool for internal use and I was the only developer on that tool. However, there was another project I was also working on. A separate project that I was a small part of. This project was mainly run by a team in China. The source of the project needed serious retooling before I could implement my part. This retooling was not needed because to the current team had coded the software poorly but because the software was the result of several intern projects over several years, and there was a lot of copy/pasted code and a overall lack of design in the source.
I wanted to check up on the source periodically so I could see where it was going, how it was developing, basically get a feel for the new architecture before I had to dive in and code in it. The problem was that the China team refused to check in their code base until it was stable. There was no trunk/branch hierarchy there was one codebase and changes between versions were not a gradual stepwise process but they were sudden and massive. They would go upwards of weeks between check-ins.
I was obviously shocked by this. Good version control practices do not involve weeks between check-ins and everyone working from one branch. I approached my manager with the problem and he understood the situation and wanted to fix it. I was quite fortunate that my manager had a Degree in Computer Science and was not interested in deadlines so much as getting a quality piece of software.
We had a meeting specifically about the process. At this point I would like to take an aside and say that the Chinese-American accent is my least favorite accent in the world. It is extremely difficult for me to understand and I personally dislike listening to it. A lot. In college I had several professors with thick Chinese-American accents and I could not understand them in lecture 90% of the time. It annoyed me more because during the short bits where I was both alert enough to understand them and they were speaking semi-coherently I recognized that they understood the material and were actually making a very decent attempt and using examples and language that put the ideas across well. Understand that I do not have any dislike of the Chinese because of this accent; it just makes the exchange of ideas harder for me personally.
That being said during the meeting we had there were several times where I had no idea what the team from China was saying. Thankfully my manager did. I tried explaining to them that once we have a solid trunk in place that is stable code for our project any changes to be made should be done in separate branches. Those branches should be checked in daily and the modified branch should be fully reviewed by the team before it is merged with the trunk. The branches should be structures in such a way that makes sense to minimize merging issues and makes logical sense with the development going on. This was a process that seemed to me a no brainer and I was shocked that they were not using it.
I then went on leave for a few days. When I got back I had emails in my inbox explaining why these methods did not make sense for the project and why they felt like they should not need to implement them. They also did not seem to understand that I was not the only one who needed to branch when the code was being modified but that no one should be touching the trunk directly. I was again extremely thankful for my manager who insisted that it was a practice that needed to be adopted by our team. He had responded to their emails before I got the chance.
I must put across that I do not believe that this was a regular practice throughout the company. I think most of the major products that we produced used best practices and that this was the exception. It just happened to be the exception that I had to deal with.
I do not honestly believe this to be that uncommon an occurrence especially as more and more software jobs are outsourced to other countries. You may find yourself in a job where you are working with people who through poor teaching or management, or simply through laziness do not follow standard software practices. And your job may get progressively harder because of this. I must admit I do not think that the team would have changed its ways if my manager had not backed me up on the practice. People are just not likely to take advise from the new employee, much less an intern.
This all said I have a few messages for people in the field of Software Engineering.
College students and new hires: learn the best practices for whatever you are working on. Use them, and instruct others to use them. Stand up for them at work if you see they are not being followed. It will make your job easier in the long run, and make a better product because of it.
Older software developers (some of this goes for new guys too): don't get lazy. Many of you know the best practices but choose to ignore them. Take pride in your work and do things right. Test your code, do personal reviews on your code, do peer reviews on your code, write your code so when someone else looks at it they will be impressed by how readable and elegant it is. Use version control. Follow the practices your company has decided you should use, and if you feel like there is a better practice or a better way to do something bring it up and suggest it.
Managers: read up on the best software practices. Buy books. Listen to your employees. Push them and encourage them to do better but don't have them working so hard they need to cut corners to make deadlines. If you can learn anything from Windows Vista and peoples unwillingness to upgrade from XP, learn that no matter how many new features and how shiny you make software, if it is poor quality software people wont buy it or upgrade to it.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment