Jonathan Crossland
Posts: 630
Nickname: jonathanc
Registered: Feb, 2004
|
Jonathan Crossland is a software architect for Lucid Ocean Ltd
|
|
|
|
A Simple Software Design Methodology
|
Posted: Mar 27, 2009 5:28 AM
|
|
No matter what software development methodology you adopt, you will always be faced with 'design' that is between good and bad, between necessary and unnecessary, between complicated and over-complicated. Design, even if it is technically good, can have disastrous effects on the project, if implemented incorrectly, or creates discord within a team, misunderstanding. In fact there are so many reasons, it would be better just to tell you what good design is. That's if I could, but I can't!.
However, I can say that Design is one of the most important factors for a project, it influences time lines more than anything else. Underdesigning, or overdesigning, neglecting to think ahead far enough, not including certain implicit requirements can all add days and weeks to a project.
Most of the time, its in your hands
A project requires thought and understanding. It takes a wide range of thinking outside of the box, thinking realistically, but yet being extremely open to ways of improvement. Here are three activities that will definitely aid your methodologies, skydiving and chess and music.
Skydiving
Skydiving, you jump out the plane, the ground is the deadline, and you simply ride the wind, and try to get finished before you hit the ground.
Developers often, within minutes, or an hour or so, are already creating the projects, setting up the design. The first design that sounds plausible, remains relatively unchallenged. If it does get challenged, you get teams of developers debating direction and throwing pros and cons, which would be good, if there was a result. However, I have seen too many meetings end in stalemate, because it gets tiring.
You cannot solve all the problems in one meeting. You cannot solve a design, or build some UML for the whole system on the whiteboard, using everyone's ideas, and thoughts. You will be there for days, weeks and many will get irritated and tired. It sounds obvious to let someone lead the design, but many projects, in todays flatten work environments want to get teamwork functioning and get the team to debate and meeting the designs. This will never work, unless it is very small, focused and within a time-frame, knowing that it may not be solved there and then.
software methodology principle number 1. Stop Skydiving.
Chess
Although we have refactoring tools, it takes real skill refactoring complex code, without breaking it, and still making it better. A large system can take weeks to refactor. In fact, most of the time, it doesn't get fixed properly. Maybe a little, but not completely.
So between "designing everything upfront" and "afterthough and refactoring", we need to consider more, and learn to read ahead.
Like chess we should actually be stretching ourselves, practising to think ahead. In chess, its relatively easy to think of a few possibilities, but to really take advantage of the board, you have to be thinking ahead, further than your opponent.
In development, we need to get our read/think ahead skills better honed.
In chess, players think about the pieces, where each piece can move to, where it conflicts with moves of other possibilities. They construct a sort of tree, an algorithm, that each player might tailor to their own abilities and skills. They build this 'possibility tree', and then asses the tree for 'patterns', set moves, known strategies, and then further they inflate and deflate nodes in their minds eye, as to each nodes are more important, are more risky, or more possible to give them maximum rewards.
software methodology principle number 2. Play Chess.
Music
Rhythm, timing, tuning and arrangement, are the pinnacles of a good band. Without it, the best songs are rendered as noise.
The first thing is to find the rhythm section. Most importantly this will be your drummer and bass player. They have to be tight. They are providing the timing and the overall rhythmic feel. Then you need the rhythm guitar, who follows the drummer and bass, he has to add a little more flare at times, but overall, he is simply giving the treble feel. The Vocalists, and backup singers are providing the stage presence, the user interface and the meaning.
Developers who understand their position and work within their area, listening to the other band members and adjusting themselves to eachother.
Playing as a band, takes a little planning. Sometimes jamming is good, but most of the time, jamming will result in a rough product, perhaps with some awesome sections, and amazing solos, but as a record, it should be well rehearsed, tight and arranged with care. Then you get quality.
By the way, you also need someone to help you get into time, practice and coordinate things. There is always a band leader. There are also many many egos in a band, and the good ones learn how to do with that, so that the focus becomes the music, not the people.
software methodology principle number 3. Play as a Band.
Read: A Simple Software Design Methodology
|
|
Previous Topic
