Well, after...erm.....10 years of developing software along slight variants of the classic waterfall model, today see's our companies first attempt at "Agile methodolgies" - in particular SCRUM.

I'm keeping an open mind, and trying to get my head around where the hell the documentation is, but I wondered if any of you guys follow an agile approach, and if you think it is usefull, or fad???

I unit test and continually integrate my code, which eases refactoring. I'm really happy with those parts of the agile methodologies. I'm still figuring out the best way to document requirements though.

Jeremy

Jeremy wrote:

I unit test and continually integrate my code, which eases refactoring. I'm really happy with those parts of the agile methodologies. I'm still figuring out the best way to document requirements though.

Jeremy

I totally agree, though I'm not completely up to speed on CI. Keeping track of everything in documentation is still the hardest part of my job. I don't think I've ever done it the same twice. I'm hoping Team Systems will help out with that some.

alex, could you elaborate a bit, just curious as to what types of docs your talking about? And what are your specific problems with managing docs. I use a standard set of doc templates that I fill in with what I need. And if the project is different, web vs. windows I have a set of doc templates for each. Now this assumes that you update the templates as needed so the the next project can take advantage of what you've learned. I assume your having other doc problems so wanted to find out specifically what they are

MattWoberts wrote:

Well, after...erm.....10 years of developing software along slight variants of the classic waterfall model, today see's our companies first attempt at "Agile methodolgies" - in particular SCRUM.

I'm keeping an open mind, and trying to get my head around where the hell the documentation is, but I wondered if any of you guys follow an agile approach, and if you think it is usefull, or fad???

Back in the days there was also agile development, we called it 'ad-hoc code hacking', i.e.: writing code without a thourough plan about every detail what you had to build, solving problems when the emerge.

I wasn't a big fan of this, and stil ain't, the biggest problem of it is that you have to think about large problems first to avoid irreversable mistakes which will throw you back a couple of months, and when that happens far in the project, it's fatal. So you can't conquer every problem 'when it emerges', you have to think ahead.

I think a 'mix' of old days visions and agile development is the most pragmatic way of doing things: think through the global project and foresee big problems, then use a more agile approach for the finer details. I took that approach with LLBLGen Pro, as the project itself was simply too big to plan ahead in full detail, at least I didnt see the advantage of spending 4 months in design phase while I have to re-do half of it during development anyway because unforeseen details which clash with detailed designs done up front.

As I said though: you have to think through the global project, predict where problem areas are, try to avoid them/solve them up front. Then, during development, per functionality aspect defined in the global project, design it first, then implement it, to prevent yourself implementing the wrong things. This works great IMHO, as when you're designing the details you already have to solve the problems and typing it in becomes more or less just that, typing it in, which avoids big mistakes in implementations.

That doesn't mean mistakes are avoided. You'll always make mistakes and the more time you spend to thinking through the project, IMHO the more you'll avoid mistakes during development.

Agile: "We can't afford to take the time to plan. Just do what you're hired to do. Write code."

Spiral/JAD: "We can't afford to hire requirements managers, so we'll just code as we let the customer tell us what they want."

Extreme Programming: "We can't afford more than one computer for each two developers, so you watch over his shoulder and 'correct him' while he codes."

The only place where I appreciated hearing "We can't afford..." was the US Air Force.
CMMI Level 2: "We can't afford to fail." Cumbersome, expensive, and 100% on target every time.

Add your own...

I like what you say Otis about a mixture being the best solution. Some agile methodologies define a runway to describe the time that you need to "think" and "architect" the solution - I think thats essention if you were to start a whole new project for example LLBLGen. I dread to think what would have happened if you completely ignored how the entity would be persisted until "iteration 10".

I'm not completely understanding agile's view on specs (functional and technial). The emphasis is on the user stories, but these to me are part of the functional spec, and agile seems to encourage little or no technical design....

swallace wrote:

Agile: "We can't afford to take the time to plan. Just do what you're hired to do. Write code."

Spiral/JAD: "We can't afford to hire requirements managers, so we'll just code as we let the customer tell us what they want."

Extreme Programming: "We can't afford more than one computer for each two developers, so you watch over his shoulder and 'correct him' while he codes."

hehe Though I must admit, the pair-programming is one of the things of XP which actually works. Back in the days when I was still programming 68000 assembler on the amiga and later on C and Java on PC on demoparties, we often sat down together and wrote code on one machine, and this was very productive, as you hardly had to think for long to solve a problem, as you could constantly discuss what you had to write and find proper solutions. Though, it depends on what kind of code you have to write ofcourse. Often the code is quite boring and you don't have to think that hard to get it right. Then 2 people with one keyboard is just a waste of resources.

The only place where I appreciated hearing "We can't afford..." was the US Air Force.
CMMI Level 2: "We can't afford to fail." Cumbersome, expensive, and 100% on target every time.

I have no experience with the US Airforce, but I do have experience with a 'think through every detail before we even get coffee' methodology and it didn't work that great, as it depends for a large part on the customer: if that's a person/organisation without a fixed, solid idea of what they need/want, you're in big trouble.

Otis wrote:

...we often sat down together and wrote code on one machine, and this was very productive, as you hardly had to think for long to solve a problem, as you could constantly discuss what you had to write and find proper solutions.

I admit it, I'm a loner that hates to work with other people. That's why I don't like XP!

Otis wrote:

I have no experience with the US Airforce, but I do have experience with a 'think through every detail before we even get coffee' methodology and it didn't work that great, as it depends for a large part on the customer: if that's a person/organisation without a fixed, solid idea of what they need/want, you're in big trouble.

I agree. Of course, the US Military knows what they want, to kill people and break things, so it makes it kind of easy.

Ok, that was a cheap shot, but truely, they do a great deal of mission planning prior to discussion of requirements for fulfillment of that mission, and much of the mission planning occurs before contractors are involved. I'd like to believe that US industry would/could do the same kind of long-term mission planning, but I've yet to see a company come close to it. Seeing as how we're (the US) not currently threatened economically as we were by Japan in the 80's, there's little call for 'getting it right the first time' kind of thinking right now.

Is that China I hear calling?

swallace wrote:

Otis wrote:

...we often sat down together and wrote code on one machine, and this was very productive, as you hardly had to think for long to solve a problem, as you could constantly discuss what you had to write and find proper solutions.

I admit it, I'm a loner that hates to work with other people. That's why I don't like XP!

hehe I also don't to work in a team which is just there because they liked the job benefits and teh company car, but if the team members are just as focussed as yourself, working in a team can really be a big gain. That is, if the team is lead professionally of course.

Otis wrote:

I have no experience with the US Airforce, but I do have experience with a 'think through every detail before we even get coffee' methodology and it didn't work that great, as it depends for a large part on the customer: if that's a person/organisation without a fixed, solid idea of what they need/want, you're in big trouble.

I agree. Of course, the US Military knows what they want, to kill people and break things, so it makes it kind of easy.

Ok, that was a cheap shot, but truely, they do a great deal of mission planning prior to discussion of requirements for fulfillment of that mission, and much of the mission planning occurs before contractors are involved. I'd like to believe that US industry would/could do the same kind of long-term mission planning, but I've yet to see a company come close to it. Seeing as how we're (the US) not currently threatened economically as we were by Japan in the 80's, there's little call for 'getting it right the first time' kind of thinking right now.

Is that China I hear calling?

I think the western societies which rely on industry a lot have a problem to face and there isn't a proper solution: the highest cost factor is often labour, and outsourcing that to low-wage countries lowers the overall cost factor of labour, however brings down the economy because a lot of people get unemployed. The sad part is that the jobs that are there for these people (in large numbers) could be highly skilled technical jobs, but the majority of people in most western societies are too dumb to be able to do these highly skilled jobs. We here have been a trading nation for centuries, so it doesn't affect us a lot, though in germany it does, and I estimate the US will suffer the same amount of jobloss in the future. This is because the people in western societies are (in general) expecting more benefits and doing less while in other countries people work harder and get less benefits. So taking a step back is for western workers in general harder, and I estimate: too hard. The domestic market of the US is still very large, so a lot of industry will still exist, but not as dominant as it is now.

I agree completely, and the solution, as always, is education. I've worked like crazy to keep myself current in this industry, and it's given me a specific edge. However, I live in a state (Oklahoma) that is industrial, and failing. I know far too many people just surviving, yet refusing to re-educate. I don't understand it.

Of course we've been an industrial nation from 1820 forward (agrigarian before that) and are still making the transition to technological. It was a major issue in the last presidential elections. The irony is that, one of our most failing former industrial states, struggling to retrain people out of the closed steel mills, was Ohio, which went for Bush and gave him the presidency, despite his opponent's opulent promises to help them. Believability is everything.

Beyond education, it is systems and processes which will save us, just as it did in our economic challenge by the Japanese. We reviewed how we do things, our processes, and we improved them, creating efficiencies that improved return on capital, lowering prices and improving quality. This is possible in technology sectors as well, through CMMI and others. People look initially and see the costs involved in training, process documentation creation, and they balk. In the long run they will do it just to survive the threat by the Chinese.

The Dutch people's history as traders and lenders is known even to this poorly educated American. How does it apply today? Is banking and lending still a major industry? Is the country a major port for Europe? What do you mean that you are still traders?

swallace wrote:

I agree completely, and the solution, as always, is education. I've worked like crazy to keep myself current in this industry, and it's given me a specific edge. However, I live in a state (Oklahoma) that is industrial, and failing. I know far too many people just surviving, yet refusing to re-educate. I don't understand it.

Well, it can be they're simply not aware of the benefits of education. If it's 'natural' to simply do highschool till you're 16 and then go to the local factory to work, 'education' isn't something which occurs to you I think.

Beyond education, it is systems and processes which will save us, just as it did in our economic challenge by the Japanese. We reviewed how we do things, our processes, and we improved them, creating efficiencies that improved return on capital, lowering prices and improving quality. This is possible in technology sectors as well, through CMMI and others. People look initially and see the costs involved in training, process documentation creation, and they balk. In the long run they will do it just to survive the threat by the Chinese.

Same here in Europe, though I doubt 1.2 billion people can be outpaced by overpayed europeans/americans.

The Dutch people's history as traders and lenders is known even to this poorly educated American. How does it apply today? Is banking and lending still a major industry? Is the country a major port for Europe? What do you mean that you are still traders?

Rotterdam was till 2004 the largest harbor in the world (number of containers per day). Shanghai took it over in 2004. Here industry always took a backseat, there isn't heavy industry (only a small part in Rotterdam) and a lot is focussed on trading/transport. A lot of multinationals have their Headquarters in the Netherlands (also due to the nice tax climate for large companies), which creates a high number of offices here. Over 70% of our population (16 million) works in offices/provides services to other companies on the business level (i.e. not industrial workers).

Otis wrote:

Back in the days when I was still programming 68000 assembler on the amiga and later on C and Java on PC on demoparties, we often sat down together and wrote code on one machine ....

Out of curiousity: what groups where you in? It might just be I've heard of you before

So all of this talk with respect to the software development lifecycle and no mention of the Microsoft Solutions Framework?

I think its a great model but it is really hard to accomplish and use properly if you dont have all 6 roles properly filled and the client and employer are not willing to spend the time on it.

Aside from that, its what I prefer. Envision, Plan, Develop, Test, Deploy, repeat.

Phew, I'm back (new PC, lost cookies.....).

I'm rather embarassed to say I know nothing of the MSF! I really should find out more, but Microsoft documents have a great way of making me sleepy sometimes....

Otis - try pair programming when the other guy is either a programming numpty, or just can't be arsed - then you'll change your mind!

Edit: I'm holding out for the Solutions Design Development Framework

Ben wrote:

Otis wrote:

Back in the days when I was still programming 68000 assembler on the amiga and later on C and Java on PC on demoparties, we often sat down together and wrote code on one machine ....

Out of curiousity: what groups where you in? It might just be I've heard of you before

Infocorner, perseus, and on PC: perseus and infuse project. I won Somewhere in holland 1 with an amiga 500 demo and takeover 2000 with a java demo (and I'm mostly known by my music (xm/mods) and my demosystem DemoGL)

Devildog74 wrote:

So all of this talk with respect to the software development lifecycle and no mention of the Microsoft Solutions Framework?

I think its a great model but it is really hard to accomplish and use properly if you dont have all 6 roles properly filled and the client and employer are not willing to spend the time on it.

Aside from that, its what I prefer. Envision, Plan, Develop, Test, Deploy, repeat.

I've never looked at it. Is it some kind of planning scheme, or a software package?

MattWoberts wrote:

Phew, I'm back (new PC, lost cookies.....). Otis - try pair programming when the other guy is either a programming numpty, or just can't be arsed - then you'll change your mind!

haha I think you're right