[sbromley]

I have been working on an agile team for a while now. At first I was all gun ho about the ideas behind agile development. In theory I'm still a big fan of what it means to have a team work in an agile way. Lately I've been noticing that maybe pushing agile development could be hurting some of the projects.

Agile development is all about getting working code out to your consumer, so that you can communicate with the consumer and see if what you have going on is really what they want, or if there needs to be some minor tweeks made. So the focus is getting a project up and running so that your consumer can see it.

My first concern was documentation and testing. I figured both of these would be lacking on an agile project. Turns out thats not the case. Documentation has turned into something that can be just as dynamic as the code. Test driven development is something that the agile process pushes as key to success. Test early and often.

So what could possibly be a negative? Design. I've always found the true beauty in a piece of software in its design. Did someone take the time to plan out how this software will work? Did they use design patterns? Did they try to use efficient algorithms? Are they using the correct tools for the job? Does everything come together and really mesh to make something that operates smoothly?

The problem I have with agile is, I feel like the design process is really getting overlooked. I see people spending time solving complex problems that amount to nothing more than jamming two pieces of software together. A lot of defects and bugs that come in are due to two pieces of software not working together nicely.

So can elegant pieces of software be designed on the fly, or are we just jamming working software in our consumer's face to get paid?

[Frinavale]

I have never had the pleasure of working on an agile development team but I have thought about the concept a lot.

In school there were many classmates that I simply could not work with. I think the biggest problem was that I understood the problem and they didn't. Since they didn't understand the problem, and what needed to be done to solve it (implementation) the work ended up being shoved onto me. I quickly found out that I am natural at leading people but what I don't like about this personal trait is that people just blindly follow! I crave a challenge and need external points of view. I guess that school isn't a good place to find this because most people are just learning concepts and like to have someone lead them around like a bunch of...

Anyways, I found someone at school who knew what he was doing. It's too bad that we met in the last year before graduation because I would have really enjoyed working with him through out the diploma program.

The great thing about him is that he tended to know a lot more than I did and so when I had an idea he would either support it or give input on a better way to do things.

Right now he is the only developer that I would consider attempting agile programing with because we know each other and think along the same lines.

The pitfall that I can see with this type of development is if the members involved in the process do not think alike (or in the case of students, some don't think at all). You would be bashing against each other all the time!

I've thought of ways to get around this problem I believe that a strong understanding of the design of the system (or component of the system...or even a method) you are developing is required.

If you have a good enough design, test cases, and a full understanding of exactly what needs to be done then the process of agile programming is going to be a lot smoother.

So, I guess, I don't understand how you can feel that the design process is getting overlooked. I would have thought that the design process would be key to this type of development.

Then again, I've never done it so I'm curious to find out more about your experience.

-Frinny

This post has been edited by Frinavale: 24 June 2010 - 09:18 AM

[macosxnerd101]

Sounds a lot like my experiences with team development. I spend more time refactoring and correcting everyone else's code than I do writing my own. Hopefully that will be different when I start my internship.

It sounds like the design process is getting way overlooked to just opening the IDE and cranking out code. If this is the "agile development process," dump it fast. If you haven't spent a good deal of time on design especially in team development environments, then you shouldn't be cranking out code. Trust me when I say it'll mean more time fixing improper integration errors (no Calculus pun intended) than writing code, and you'll possibly end up frustrating the client. Once you have the design done and a high level overview of how the components should work together/be integrated, then start cranking out the code.

Remember, you aren't just handing off the clients a piece of software and running. You are also writing a framework for other developers to extend and maintain. As a rule of thumb, I write code as if the person maintaining it is a psycopathic killer that knows where I live. I really don't want to piss him off with crappy code and wasted time.

[Frinavale]

macosxnerd101, on 24 June 2010 - 07:43 AM, said:

As a rule of thumb, I write code as if the person maintaining it is a psycopathic killer that knows where I live. I really don't want to piss him off with crappy code and wasted time.

Haha

I think everyone should develop this way!

-Frinny

[xclite]

I feel like Agile, done perfectly, is good. Agile on huge, old projects seems to be a clusterfuck.

[sbromley]

Good to hear I'm not crazy for having concerns.

I do like a lot of the Agile in theory, but in practice, on a large scale if feels more like a something the business side of the company is forcing on developers in order to get things done faster. Maybe its because the full extent of the Agile model hasn't been fully embraced. There is a lot of untraditional practices in Agile especially for developers. Test Driven Development is one of the biggest that comes to mind for me as well as interfacing with the consumer of my solution.

I would like to see just as much emphasis on code quality and developers as delivering consumables and the customer. The Agile model in theory has that emphasis, but in practice it does not.

[CTphpnwb]

Think about the last time you applied for a programming job. How many HR people did you need to go through before you talked to anyone who knew anything about the language(s) being used? My point here is that no development method can overcome a system in which you get hired by people who don't know anything about the job. Agile is fine in theory, but the reality is that too many who look good on paper and can talk a good game but really have none, will get hired. Then it's just a matter of whether or not the good ones can overcome the handicap or not.

[Ace26]

sbromley, on 24 June 2010 - 06:52 AM, said:

The problem I have with agile is, I feel like the design process is really getting overlooked. I see people spending time solving complex problems that amount to nothing more than jamming two pieces of software together. A lot of defects and bugs that come in are due to two pieces of software not working together nicely.

So can elegant pieces of software be designed on the fly, or are we just jamming working software in our consumer's face to get paid?

Actually the kind of design agile processes(like XP) advocate is quite a safe one- continuous redesign. Make it work, run failing tests, refactor, make it work, run failing tests,...... It continues this way till you have it right. And remember that your customer isn't after your design documents but his working software(which is the major goal of agile processes).

Refactoring which is an important component of XP, is in it's right a design (and redesign) activity. If you are refering to one-off design (using UML), i'll have you remember that requirements are in a state of continuous flux which prompts redesigning each time. So i'd rather make it work, then make code look elegant, maintainable and readable(refactoring). Agile processes don't overlook proper designing of software in anyway.

[macosxnerd101]

Refactoring is one thing, redesigning is a-whole-nother thing. Obviously, refactoring can be a useful process if it produces some significant improvements in the code. However, redesigning the program on each iteration of the cycle is, in my opinion, a waste of time. Yes- there will need to be some changes to certain features and certain additions to the overall design. However, unless you have a really bad design to start off with, scrapping your current design and starting over (which is what I'm inferring from your saying "redesign") is a very time consuming and inefficient process that won't do much in the way of better quality control. Quite the opposite, as it will take away from the time you could have been using to refactor and enhance your previous design.

Quote

Make it work, run failing tests, refactor, make it work, run failing tests,...... It continues this way till you have it right.

This sounds like a normal part of programming to me.

Quote

And remember that your customer isn't after your design documents but his working software(which is the major goal of agile processes).

Maybe not the clients you are dealing with, but maybe they have IT people who will be maintaining this. As they can be your best advocates in the client organization, make it easy for them to maintain your code. Proper design and documentation is part of this.

Quote

So i'd rather make it work, then make code look elegant, maintainable and readable(refactoring).

This sounds to me like a get it working vs. get it working the right way moment. As project deadlines creep up fast and are in a constant state of flux, better to get it working the right way once and move on, rather than have to worry about coming back to it.

This post has been edited by macosxnerd101: 24 June 2010 - 03:33 PM

[SixOfEleven]

I would work well in an agile team but I'm not sure I would want to. I can throw code at a problem and come up with the solution by trying, testing, if fails then try again. It isn't something I would do for a large project I was leading or designing. For smaller parts of a large project, sure, throw code at it. The project as a whole would have to be well thought out though. There would have to be a plan in place for the interaction between the various parts of an application. Those parts should have some planning. The parts of the parts is where I would start throwing code at the problem.

That said though, I would never use code that didn't work 100% right all of the time. It is a matter of getting it working right more than just getting it working.

[The Neoracle]

sbromley, on 24 June 2010 - 09:52 AM, said:

So what could possibly be a negative? Design. I've always found the true beauty in a piece of software in its design. Did someone take the time to plan out how this software will work? Did they use design patterns? Did they try to use efficient algorithms? Are they using the correct tools for the job? Does everything come together and really mesh to make something that operates smoothly?

The problem I have with agile is, I feel like the design process is really getting overlooked. I see people spending time solving complex problems that amount to nothing more than jamming two pieces of software together. A lot of defects and bugs that come in are due to two pieces of software not working together nicely.

So can elegant pieces of software be designed on the fly, or are we just jamming working software in our consumer's face to get paid?

I've done Agile in one capacity or another for going on 3 years. Specifically XP and I've worked for a signatory of the Manifesto.

XP has 4 Coding Practices:
1. Code and Design Simply.
2. Refactor Mercilessly.
3. Develop Coding Standards.
4. Ddevelop a Common Vocabulary.

XP has 4 Developer Practices:
1. TDD.
2. Pair Programming.
3. Collective Code Ownership.
4. Integrate Continually
(and for web applications I'd change that to "Deploy Continually").

Are you doing those? Are you doing a subset of those? Of the ones you aren't doing, why aren't you doing them and how might they address your issues?

[The Neoracle]

Ace26, on 24 June 2010 - 12:52 PM, said:

sbromley, on 24 June 2010 - 06:52 AM, said:

The problem I have with agile is, I feel like the design process is really getting overlooked. I see people spending time solving complex problems that amount to nothing more than jamming two pieces of software together. A lot of defects and bugs that come in are due to two pieces of software not working together nicely.

So can elegant pieces of software be designed on the fly, or are we just jamming working software in our consumer's face to get paid?

Actually the kind of design agile processes(like XP) advocate is quite a safe one- continuous redesign. Make it work, run failing tests, refactor, make it work, run failing tests,...... It continues this way till you have it right. And remember that your customer isn't after your design documents but his working software(which is the major goal of agile processes).

Refactoring which is an important component of XP, is in it's right a design (and redesign) activity. If you are refering to one-off design (using UML), i'll have you remember that requirements are in a state of continuous flux which prompts redesigning each time. So i'd rather make it work, then make code look elegant, maintainable and readable(refactoring). Agile processes don't overlook proper designing of software in anyway.

Kent Beck's (inventor of XP, TDD, and lots of other really good ideas) current philosophy when it comes to design and refactoring is one of "Responsive Design". You can see a presentation on it here: http://www.infoq.com...sponsive-design

[pbattisson]

I think the issues you are seeing here are in fact a problem of the way you are doing agile development, not agile development itself.

I am a Certified Scrum Master and for the past year have been involve in a team performing scrum (an agile methodology) as well as having previously brought scrum into a team. Often I hear people further upstream (Business Analysts, Product Owners, Managers and when starting out some Technical Architects)say that they are worried about the fact there is no design phase and that this could lead to an unscalable or poor design. However if done in the right way agile development leads to an inherently improving design.

All agile development methodologies use iterative development, most commonly doing a certain amount of work in a "sprint" before moving onto the next iteration where you do another set amount of work. This means that you will have to make some design decisions in each iteration for your current work, but only enough of a decision to cover you for the work you are doing. If then next iteration your work highlights this is a poor decision, you have a minimal amount of refactoring to do do create a better design.

People often mistake "design" with "schematic". A design is merely a plan for a project, and in agile development we are only planning the work we will be doing this iteration. A schematic is a complete read out of exactly what needs to be done and how, and this is often given in a waterfall setup. By just designing what is to be done this next iteration - making a plan of what you are going to do you allow the best decision to be made at the time of doing it rather than have to stick with a pre-defined structure that may no longer be applicable.

For a video by Ken Schwaber where he talks about the design process see "Scrum et al" or read the following.

[sbromley]

Alrighty, so from what I'm hearing it sounds like we think of design on a smaller scale, than what I previously had in mind. From project to project the design I get from an architect is usually pretty good, if I need one at all, but the big picture was what I was initially concerned about. I certainly do a good amount of refactoring from sprint to sprint, and it does keep code up to date, within a certain style, and overall just easier to work with in the future. The team I work for uses tool for continuous integration, so we always know everything we develop works with everything else.

So then from an Agile standpoint is the design process that my team has implemented sound? Same questions from just a software in general standpoint?

Also for people that started recently or people that have been using agile for awhile, do the developers actually use TDD and pair programming? From The Neoracle's list, my team implements all those things except TDD and pair programming. I'm wondering how long, if ever, does it take for those things to catch on with developers.

[sujayg]

A very interesting thread . I recently attended a SCRUM meetup and I had a simple question . Maybe I shall get my answer here

As regards design patterns, I can say, it is not neccessary to follow design patterns everywhere, as it might be an overkill - so sometimes, following a good design is better than following a design pattern

The question is - I am following a process which delivers quality output to my customer in time. As a team , we work on peer review, NUnit testing, automated testing , internal meets to know where do we stand , etc . ... but I am not following any methodology as such .

In this scenario , what is the benefit of moving to SCRUM .