I used to work for a large multinational, with a gigantic development team (several thousand developers) working on a 30 year old code base, with many millions of lines of code, originally written in C and slowly translated into C++. I know work for a small Melbourne based web development company, working with a small development team (~10) on a product that is around 5 years old, with around 250 thousand lines of code, originally written in VB.Net and now being mostly written in C#.
Obviously the differences between the two extend beyond the differences in their respective projects and code bases. Perhaps the most jarring difference, although not the most surprising, is the different styles of code design, development and testing. At the old company, as a result of the complexity of the product and the environment in which it is developed, the software development life cycle required large upfront code design efforts and very defensive coding practices. At my present company for the most part there is less need for upfront design and more ability to adapt a design as it is being developed and tested. At the old company there was a large set of established processes for everything from feature approval to how to test systems, at the new company, there are very few established processes beyond code management and release delivery.
At the former company given the age of the code base and the incremental nature of feature development I coined the term Glacial Agile to describe our software development process. We where essentially doing agile development, we would add one or two features per iteration with a bit of design up front and testing at the end, but instead of taking a two or three weeks as you would do in a normal Agile process, it took us 6-9 months per iteration. If you take this over the life of the project, 30 years, then it doesn't seem as bad.
While I was at this company there where many efforts to try and get all the development teams to switch to Agile Development, often it seemed only because a manager read about it somewhere and wanted to be an instigator of change. For some of the projects this made sense, but not the core product of the company. The established process, while often frustrating, had been honed over many years to the point where it was quite good at protecting the product from failure and introduced bugs, but not so good at adding new features.
At my present company, we are still working on the processes, currently code reviewing is being trialled. For the purpose of this blog post I'm going to call the process here Whatever. The reason that there isn't much process in place is because the current system kind of works, it has been built up by the people that work here slowly and is for the most part contained in a few peoples heads. Actually, upon reflection, it is wrong to say that there isn't much process. There are indeed a variety of processes that are used and have been developed over the last few years at the company. What is missing is a formalized version of the processes that are used. All the processes are stored in the heads of those that manage the projects, I shudder to think of the impacts of one of the key players stepping in front of a bus, but it could set us back months in product development (not to mention of course the emotional effects).
As an example, when I first started here almost a year ago, there was no instructions, no document, or even a rough outline of how to setup a system to run source code, no instructions on how to setup the Databases etc. I had to ask a few different people to help me set up my system and between them they managed to get everything covered. Knowing that I would have to setup quite a few different systems in the future I tried to cram everything into a document (which reminds me that I should probably update it) and then tried to find somewhere to upload it, it is still sitting on my own computer.
While the Ad hoc processes do, for the most part, work quite well they are getting less effective as the company and product grows in size and complexity. The introduction of formalized processes will be a long and probably slow process, most of the employees have never worked in large companies and they are not familiar with working with formal processes. We all enjoy the informal nature of the work that we do here but I can't help but feel it would benefit from a little more structure around some aspects of the work. In particular to me we're working on a section of code for a new feature and it has been rewritten several times and even now a few weeks shy of when we intend to release it, we are restructuring and changing class names etc, this could have been combated with more upfront design and analysis.
It is heartening to see that we are employee more aspects of rigorous software development, and in the future we can only hone and improve the processes that we do have. Now, if only I can persuade people to get all this stuff written down it can only help our planned efforts to grow as a company. The other day there was a discussion about having another development or test team located somewhere else in the world (such as the US). This caused great angst among everyone as they thought it would be too hard to work in that situation. While I tend to agree that it is easier to be able to work on something when you can walk over to everyones desks, it is not overly hard to work with people spread all over the world, if there are good processes and communications systems in place.
I've tended to ramble a bit here, but I guess the point is, at the old company I found the process restrictive and at times quite annoying, it is only by moving to a small company with not very many processes that I appreciated the power and the need for a solid set of processes to work with. Eventually we'll get processes in place for the whole development processes and I continue to aim for this. We've got code reviewing in the process now (although annoyingly not as a result of my efforts over the last year) and we'll continue to develop better processes in the future
No comments:
Post a Comment