I feel one of the biggest challenges with managing or orking in a busy software team is picking up where someone else left off.
You know, when some one gets ill, leaves their role, or get's pulled onto a another project some one else has to get their head aroun the code that's left. Sometimes it just a ess and that;s the only ay of describing it. Most often thugh it looks like a mess to the newcomer, but to the guy who has been maintaining it for these past few months or years it has it's own organisation and plogic.Once you understand it you'll be right at home.
The trouble is there's normally very little info as to ho to get your had roun all this and you're never given any tiime to get up to speed. Most often you're picking it up bcause your boss needs you to get something done using this code. Heaven knows how the lat guy got things sorted but you surely don't kno where to start.
Ok that as a quick intro into how my software life has otn been. So often you come it sort things out and you've got to gt up to speed quiclly.
Well I wonder if it has to be this ay at all. My first IT job was on a computer helpdesk that run 24x7x365. We also had upwards of 2000 contracts t support so you ca guarantee that there were a lot of diffrent peole involved, different copmanies to ork ith and diffrent orgniational cultures.
We still managd to get a high quality job de though and it was usually obvious why things workd better on one contract or for one organisation than it did for another. Most important as always communication. Do the people along the chain communicate well and use their available tools to their potential. That was the key.
In the xample given above I would want a developer to provide me with alittle information bout his coding style and the loic her uses. Not an essay fbut a few tips and poiners. Myself use design pattern philosophy and try to determine the patterns that occur in an script or cde base and then rovide common solutions for these. Then each script just usese these solutions in hatever order is necessary. So things a re loosely coupled and there is a clear contract between the function or method nd its caller. I don't rigidly fllow the design pattern approach mrely I realise there are patterns and as I gain more experience will be clearer abot which pattern I am using.
Ok that's a little air fairy but feel it ould give you a little idea abut the ay I code and would help you make better use of the code that I write.
for eampleit means that I create lots of functions, methods and classes. All seemigly separate nd self contained. Thn I just chain these together in any script I write. So all these methods and fucntions alll ork together but as a whole they work like an MVC approach that's extrememly flexible in its application.
So if you ere trying to work with my code you might realise tha reuse of key methods and functions (patterns) is key. By knoing this you'd pobably ant to figure out the key methods relevant t hat you want to do. Leanr a little about them n thn search the code bas e for examples f how to use them.
So often with my code if you just use n example that previously worke and then configure it a lttle differently you'll have a chance of getting hat you want.
Other people hoever generally have their nn approach. One application in Moodle made no sense t me until the developer expained it as simply portlet based pproach taken from Java ith xforms. All of a sudden code I'd been struggling to understand for 2 years made lots of sense ecause I'd been working on the same approach albeit in a different langage previously.
You see just a few short sentences can make a mess of code trn into a nice ordered and understandable application.
So what does this t a lving breathing team. In short each developer should spent some of their time working on another developers code. My suggstion would include bug fixing. If ach week everyone did a little bug fixing uing something like bugzilla to mange the bugs. Then everyone culd take a bug for a peice of code the don't know so well and basically try and fix it.
Woah nelly, you mean just fix someones code straight off. Of course not. That's the end goal. I realy meean build in progrssions from the easiest being the guy responsible for a peice of code fixes a bug with another developer looking over his shoulder. This way quality is maintained an the novice on this codebase can't muck things up. The problem is that they won't learn so much. the other extreme is when the bug gets assigned to a guy who has had no introduction to the code at all. He is then expected to just pick up the ug and fi it within certain time limit.
Ooh can see a fun competition emerging out of this.I like gaes. e might get to that later. Any waythe latter example is here you are aiming to be. If it's possible for someone who has never seen your code before and never met you to maintain or develop your code quickly then you must have done hell of a job and your code must be really easy to maintain. Well done you must be amazing.
Well, this may see impossilble to some, opefullyjust difficult to others. To me it's well within the realms of possibility. Yo see I told you I worked on a helpdesk. ften I never mt the people ho resolve the issues I logged. Yet hen it came to bonus time I did really ell once i'd been working on th helpdesk for a couple of years. The reaon. I'd learnt a lot about communication. About how tofigure out what some one else ould need to kno to be able to not only resolve the issue but to comunicate ith the person logging the call.
Since software development is in essence a set of bugs (problems) and features (solutions) surely the skils learnt on a helpdesk would e useful in a development team. I think so. If each developr routinely spent a small portion of their week fixing other peoples code then they'd make damn sure their own code was easy to understand and work with too. Sort of a pay it forward approach. You'd also find that all sorts of advice woul pop up on wikis and blogs in the team. Since everyone woul have t chip in everyone would care aout having a standard approach to things hile still being able to code the way they're used to.
Things ould be awkward for a little whle but quickly everyone would agree on some simple standards to follow. thigns like documentation within code, common words and acronyms to use, method signatures, here to pt supporting code and documentation. here test scripts are stored and run. Where info supporting the project should be stored and what it should include.
Once you've got this figured out you'll most likely find that when the'@:: hits the fan you're all set to deliver much faster an with fewer bugs than you ever have before. Why you all begin to speak common lanauge, know ho to work with each other and spend more time going forward, working on keys tasks, than you do looing ackwards and fiing things that shouldn't have gone wrong in the first place.
No comments:
Post a Comment