|
"Engineering without management is art." -- Jeff Johnson 
Best regards,
Alexandru Savescu
|
|
|
|
|
I used to believe that everything had to be designed before a single line of code was written. I have even attended company-sponsered classes that promote this idea.
Then I grew up.
The reality of the situation is that you never have all of the answers, nor do you even know what all of the right questions are when you first start a project. You have to realize that the more complex a project is, the more milestones you will have to set. Each milestone can be designed, coded, and tested independently of the milestones that come later. This is considered iterative development, and most of the "Process Police" people strongly disagree with it.
I worked on a project a couple of years ago, and the Technical Lead liked some of the concepts presented in the "Extreme Programming" methodology. When he explained it to the customer, even the customer was excited, because they would have frequent releases to work with, and new features with each release! Here's what we did:
First, we sat down with the customer and asked what new features he would like, and what bugs he had found and needed to be fixed. Then, we would look at the schedule and determine how much we could actually accomplish given the time and financial constraints. Next, we would tell the customer what we could do, and get his authorization to proceed.
From that point on, each defect fixed or feature developed was done in a tight iterative cycle, usually by a single person. The engineer would determine what needed to be done, and how long it would take. He would do as much design work as was necessary (in other words, the process police hated us because we didn't fill out fifty pages of forms for each requirement-design-code-debug-release cycle) and have someone else review it for consistency. He would then make a branch in the revision control system, code it, debug it, and have our test engineer regression test the entire application. Once everything was verified, the branch would be merged back into the main line code.
This entire process usually only took a day or two, because it was done on a rather informal basis. But, the customer was always happy, because it looked like we were making a lot of progress! We would make a release available every Friday with whatever changes had been made on the main line. This was possible because everyone worked in a branch instead of on the main code. The "main line" would ALWAYS be in a consistent state.
You do NOT have to plan EVERYTHING up front to be successful. If you have a good CM plan and everyone, including the customer, sticks to it, you won't have any trouble.
--
Paul
"I drank... WHAT?"
|
|
|
|
|
Paul A. Howes wrote:
. He would then make a branch in the revision control system, code it, debug it, and have our test engineer regression test the entire application. Once everything was verified, the branch would be merged back into the main line code.
This sounds like a big pain in the rear:
1. Branch the source code.
2. Check out the needed source files from the branch.
3. Make the changes.
4. Check the files back in.
5. Build the files.
6. Test the program.
7. Merge the changes back into the main line.
8. Build the files.
9. Test the program.
10. Release to customer
Why not this:
1. Label the main line.
2. Check out the files from the main line.
3. Make the changes.
4. Check the files back in.
5. Build the files.
6. Test the program.
7. Release to customer.
Regards,
Alvaro
|
|
|
|
|
Alvaro Mendez wrote:
Why not this: (snip)
This is good for a single developer. In the multi-developers and multi-release (means at any single moment there can be many active and released versions of the same application) you need the branching and merging.
|
|
|
|
|
George,
You are exactly right. We had a fairly small team (six people) but each person had an area of responsibility. Unfortunately, some of the subsystems did have interdependencies, which required a fair amount of testing before a release.
The process may seem like a pain in the rear, but the whole point is that if done properly, the main branch in the repository NEVER BREAKS. We would create a label for releases as they were made, so we could go back in time to fix problems with a specific release, and merge the fix back in to the main branch.
But, from the customer's point of view, the build created from the main branch was a very stable beta/release candidate.
--
Paul
"I drank... WHAT?"
|
|
|
|
|
Paul A. Howes wrote:
The process may seem like a pain in the rear
I think it depends on the way you make a "merge" part. With the proper version control (CVS, P4 etc.) you can make merges with ease in any direction. With Visual Source Safe (which is really like a very unreliable centralized backup system rather than version control system) it would be almost impossible to work with braches.
Hey, you should see what they have in places like Lucent Technologies - that is a pain to exteme! However you have to keep in mind that they have to make few thousand developers cooperating and it's not easy...
|
|
|
|
|
Yep, if there are multiple versions of the same software being maintained simultaneously, then branching is a must. But branching for the sake of fixing issues on one particular version is just unnecessary work, regardless of how many developers are involved in the process.
In other words, let's say I have a VSS project called "Version 3.0" and a group of developers will need to make fixes on it. There's no need to create a separate branch just to fix bugs on it. Simply create a label on the project and fix the issues directly on it. It's quicker and simpler.
Regards,
Alvaro
|
|
|
|
|
Alvaro Mendez wrote:
But branching for the sake of fixing issues on one particular version is just unnecessary work
That depends on how big is a change required to fix the bug. For a great changes branch would make sense as it allows to see the changes more easily and branches are good to help organize the co-operation of multiple developers wokring on the same problem together. Once the fix is complete you merge it and cloes the branch.
Alvaro Mendez wrote:
In other words, let's say I have a VSS project called "Version 3.0" and a group of developers will need to make fixes on it. There's no need to create a separate branch just to fix bugs on it. Simply create a label on the project and fix the issues directly on it. It's quicker and simpler.
Well, if you are using VSS then you will only get frustrated doing the branching because merging is very badly and poorly supported. If you also use the exclusive checkouts model then you will block the work on the software for other people when you make a checkout for your bug fix, which is definately not quicker. The branching is usefull only if your version control supports it properly and VSS is a very simple and outdated version control. It also tends to corrupt the version repository, but that is another story.
|
|
|
|
|
George wrote:
The branching is usefull only if your version control supports it properly and VSS is a very simple and outdated version control. It also tends to corrupt the version repository, but that is another story.
You forgot to mention that it is extremely buggy. Sometimes when I've checked in changes in a file, and then another developer checks out the file, changes it and checks it in again, my changes are lost!  I suspect that this is some VC6<->VSS problem.
Other times when I update my local files, VSS simply ignores me and won't do it. Eventhough its own diff tells me that there is a difference between my local files and the repository!
We've dropped VSS now in favour for CVS for these bugs and the much easier branch handling.
|
|
|
|
|
Because that solution only works when there's one customer-required branch at a time--certainly not the case around here...
Tim Lesher <tim@lesher.ws>
http://www.lesher.ws
|
|
|
|
|
My solution was based on the idea of fixing bugs on a given release (or branch, if you will). If you've already created a branch for a particular version of the software, there's no need to create yet another one for the purposes of fixing bugs. This is what I understood that Paul was doing -- creating a branch just to fix bugs, and then merging it back to the main branch, and releasing off of the main branch. There's just no need for that, IMO.
Regards,
Alvaro
|
|
|
|
|
Paul A. Howes wrote:
A better way...
How does your methodology handle new developments? You only mention existing applications and extending or fixing them.
Just curious 
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Sonork ID: 100.9903 Stormfront
|
|
|
|
|
Paul,
The same method actually works for new development. The steps either way are fairly straightforward:
- Get the customer's requirements.
- Have your engineering team determine which requirements can be accomplished with the time and money available.
- Verify this goal with the customer as being the product of the first non-beta release
- Work up a schedule of milestones. Remember, you don't have to accomplish everything in one go. Give your team bite-sized chunks that they can show rapid progress in.
- Have the engineering staff draw up a design for the first milestone.
- The design should be verified by the team leader, or at least another team memeber.
- Write the code for your unit tests that verify each part of your design.
- Code to the design, updating both the design and the unit tests if something needs to be changed
- When all of the unit tests pass, hand the code over to your test staff, and let them break it.
- Fix any problems found and repeat the test phase until no more issues are found.
- Create a tag and make a release available from it.
- Repeat design-code-test phase for the next milestone.
This may seem like a lot to go through, but the steps are "well known" to most software engineers. The thing that really makes this work is that the customer is involved in the testing process at each release. What your test people are hammering on is the "alpha" code. The customer works with the "beta" code. Because you are receiving constant feedback from the field, you are able to catch problems immediately, instead of many months later, when the problem will be that much harder to find.
You might want to read the book "Extreme Programming Explained" by Kent Beck. That is where most of this came from. I don't agree with all of the concepts that he presents, but the idea of dividing the work into very short (1-week) iterative cycles is very appealing. You show rapid progress and defect management is ongoing, instead of a massive push at the end of the project.
--
Paul
"I drank... WHAT?"
|
|
|
|
|
Our procedures dictate that the design is done and reviewed before coding starts. Unfortunately the delivery schedule is usually imposed on us from outside, so in reality design starts and is documented and at some stage during documenation the coding starts so that the schedule can be met. The only time we can push the schedule out is when the specs from outside are delayed.
Happy programming!!
|
|
|
|
|
This is one of the biggest problems that developers face. The only people who can say how long something is going to take is the people who are actually going to do the work. You never know how long something is going to take until you've done the design.
Michael
|
|
|
|
|
Michael P Butler wrote:
You never know how long something is going to take until you've done the design.
I would say: "You never know how long something is going to take until you've finished it."
I vote pro drink ![Beer | [beer]](https://codeproject.freetls.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
Come on there have to be more.....
I know there is from all the crap I have to clean up a few years down the line. That, or I'm the most unlucky bloke, to ever encouter so many cut and paste contractors that just loved to code when badly hungover.
I know your out there soemwhere, and I've got your names at the top of each module, about the only thing you could spell correctly, or bother commenting in.
-------------------------------------------------------------
Can you guess, I've had a fun day.
Giles
|
|
|
|
|
Common on .. we are not dumb enough to put our real names in the file headers
|
|
|
|
|
....
If the project is my own, I only design the hard parts, or perhaps the overall framework. Otherwise, I'm the customer and the developer, so there's no penalty for design changes.
If the project is for someone else, I demand a thorough design up front. I hate doing speculative programming for other people - tell me exactly what you want; if you don't, you won't get it.
-c
Smaller Animals Software, Inc.
|
|
|
|
|
Chris Losinger wrote:
If the project is for someone else, I demand a thorough design up front. I hate doing speculative programming for other people - tell me exactly what you want; if you don't, you won't get it.
 I've never met any customer who was able to tell me exactly what he wanted.
I vote pro drink
|
|
|
|
|
Nemanja Trifunovic wrote:
I've never met any customer who was able to tell me exactly what he wanted.
That is why you spend a good week to three weeks with them developing the design.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
Paul Watson wrote:
That is why you spend a good week to three weeks with them developing the design
OK. But Have you ever experienced something like: "We would really like you to add this little feature" when the project is in the final stage. Of course, you can always say: "No, no! This is not in the specs", but they will not be happy to hear it. And the bottom line is to make them happy, isn't it?
I vote pro drink
|
|
|
|
|
My time is their money. If they want the feature, and want me to put it in, they have to pay for it.
-c
Smaller Animals Software, Inc.
You're the icing - on the cake - on the table - at my wake. Modest Mouse
|
|
|
|
|
Depends on who the work is for...
That is very very true!
Very very very true in fact.
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Chris Losinger wrote:
- tell me exactly what you want; if you don't, you won't get it.
I believe customers NEVER know what they really want
Mazy
You can find a solution (even a foolish one) for all problems (even big ones)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
