Posts tagged as:

agile

Andy Hunt is the author or co-author of several programming books including:

  • The Pragmatic Programmer
  • Programming Ruby (the Pickaxe book)
  • Pragmatic Unit testing in C# with Nunit
  • Practices of an Agile Developer
  • Pragmatic Thinking and Learning: Refactor Your Wetware

He’s also one of the original signatories of the Agile Manifesto.

Andy is a great person to talk about regarding Agile Development. Here are some things he says you need to become agile and where to start:

  • Do a little of the right things all the time
  • You’ll be the expert on the project at the end of the project. Defer important decisions until you understand the problem.
  • Stand up meetings
  • Set ground rules
  • Make sure you have a stable build environment and version control
  • Unit Tests
  • Continuous Integration
  • Code Reviews/Pair Programming – Check the code
  • Involve the Customer
  • Produce something every 1-4 weeks
  • Retrospectives – Get Feedback

Download this Episode

{ 2 comments }

Joe is one of the talented developers at Thoughtbot in Boston, MA.

Joe is a maintainer for the shoulda gem. Here’s a video on how to use shoulda.

Some of the gems we talked about are:

Thoughtbot is responsible for HopToad.

Joe also mentioned that Thoughtbot uses Pivotal Tracker and most developers use VIM. His VIM config files are here.

Here’s the article on Team Rotation.

Download this Episode

{ 1 comment }

Here’s the link to the pledgie where you can help me get to RubyConf. Click here to lend your support to: Send Charles to RubyConf and make a donation at www.pledgie.com !

This week’s episode is an interview with Corey Haines. He’s pretty well known as the Software Journeyman and his coding tours where he traded time pairing on code for room and board.

You can keep up with him at http://coreyhaines.com.

You can also check out the following links for other things he’s doing:

Here’s a link to the Software Craftsmanship Manifesto which is tied a lot to the discussion we had on Software Craftsmanship.

Corey mentioned the Structure and Interpretation of Computer Programs – 2nd Edition (MIT Electrical Engineering and Computer Science)
book, which is a mind-blowing set of instruction and exercises for computer programmers.

We also discussed pairing in relation to the code retreats. Corey mentioned the paper by Arlo Belshee called “Promiscuous Pairing and the Beginner’s Mind”

You can reach Corey on twitter as @coreyhaines and by email at coreyhaines@gmail.com

Finally, checkout the latest news on the XP Universe conference.

Download this Episode

{ 1 comment }


Estimating your workload can be tricky, but most management, marketing, and sales departments want to know when new features or bug fixes will be out so they can project where what they’ll be able to sell in the future.

You can estimate on the following scales:

  • T-shirt sizes
  • Fibonacci Numbers
  • Algorithmic/Exponential scale
  • Linear scale

You can estimate in several units of measurement as well:

  • Points (Complexity)
  • Hours
  • Days
  • T-shirt sizes

Overall, estimation can help you inform timelines, identify problems in features or your development cycle, and open discussion on tough features.

Download this Episode

{ 1 comment }

Asking people what Agile development is is like asking people what math is. You could get answers varying from specific operations to branches of math like algebra or calculus. The answers the Agile question vary from specific practices of certain Agile methodologies like pair programming, standing meetings, sprints, and sprint boards to ‘not waterfall.’

The real answer depends on which question you’re trying to answer. “What is Agile?” usually translates to one of the following.

  • What is at the core of Agile development?
  • What is the purpose of Agile development? What is it trying to solve?
  • How do I implement Agile development?

Let’s dig into these questions.

What is at the core of Agile development?

The traditional core of Agile development is the Agile Manifesto. The Agile Manifesto states:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

I wrote a post over at the Business is Pleasure blog on where agile methodologies break down. The post also covers the general principles behind agile development. Since I don’t want to duplicate content, I’ll summarize here.

In general, the focus of the Agile Manifesto is basically to:

  • allow people to excel according to their strengths, rather than according to the system.
  • make sure software works, rather than get caught up in documenting what it should do.
  • make the software usable.
  • involve the end user and business people before you march too far down the wrong road
  • adapt to changes—after all, we’re dealing with real life, here.

What is the purpose of Agile development? What is it trying to solve?

Most Agile proponents would answer this question by explaining the Waterfall method. However, I think the supposed anti-pattern that the Waterfall method represents distracts from the point of Agile development rather than defining it.

Agile development is really about providing a framework that allows developers to build something useful for real world users and deal with the realities of interruptions, timelines, and technical requirements that disrupt an ideal development cycle. In other words, Agile development helps developers deal with reality.

Certain practices, such as iterations, pair programming, code reviews, and retrospectives help developers and development teams adapt to change, avoid or fix bugs, and find ways to employ their strengths to build great software.

Let’s face it, if a programmer or team knew what the ideal product was when they started coding and could work uninterrupted until they were done, they would get pretty close to the ideal product. However, product development never works this smoothly. Typically, a prototype is developed, shown to a few users, taken back to the drawing board to be molded into a better prototype, over and over again until a prototype appears that is good enough to be called a ‘product.’ We then stamp a version number on it and ship it.

Agile helps us deal with these types of interruptions and reworks that are part of the reality of building software.

How do I implement Agile development?

This is where the things get crazy. Everyone seems to have a horse in this race. The Extreme Programming (XP) people think they have the ultimate way to build software. The Scrum folks think the XP folks have missed the point in some aspects. The big name agile coaches and book publishers want you to follow methodologies that benefit them.

So, what is the right way to go? A lot of people will tell you a lot of things. The one thing that many people won’t tell you is “Do what works for you.”

Agile development’s first tenet according to the Agile Manifesto is:

Individuals and interactions over processes and tools

This tells me to do what makes for the most effective interactions and individuals. This implies that you know your strengths. If you don’t, don’t worry. You’ll figure it out as you go.

I recommend to most people that they look into XP, Scrum, or some other Agile methodology they’ve heard of. Choose one or two of their practices and try them out. A good try will occur over a few months. If they don’t work after you’ve gotten used to them, find ways to modify them so you can get the benefits from them and minimize the problems you’re having. Or stop them altogether.

The Agile methodologies are a good roadmap for solving your programming process’ problems, but they are not the destination. The destination is great code. The practices behind Agile methodologies can show you the roads to get you there faster.

I’ve never met anyone who had 100% adherence to a particular methodology work for them. But I’ve seen people get close and get results.

Conclusion

Overall, the confusion about Agile development comes from one of its strengths. You define how Agile works for you. It’s similar to the principles of good living that most people get from their religion. There’s a huge amount of overlap in the religions out there, you just have to find what you believe to be truth and then do your best.

{ 5 comments }

This year’s Agile Roots conference is focused on building great software. They have a terrific line up of speakers and it only costs $250, which makes it a great deal! The conference this year focuses on the development process and how it formulates requirements that lead to great software. Not just great software to maintain and build. But also great software that provides value to users.

Andrew explained that we, as developers, need to realize that we’re enabling a business experiment, not just building code.

He also went into the value we receive from open source software. The problem some of these people have is collecting the value of their work. You don’t get paid for being smart. Rather, we need to find ways to receive value from what we’re providing, even if it’s not designed specifically to make us money.

Pat Maddox wrote a blog post called “Are you punching your users in the face?” It was designed to help people to understand was that the value of the code isn’t in the tests or the code itself. Its value is in building software that users want to use.

We got a great recommendation to read “A Big Ball of Mud”. The author asked “What do you call someone who writes code like this?” after talking about every antipattern and code nastiness and he said “millionaires.” Historically this is true. Someone solved someone else’s problem with ugly hacky code, and walked away with millions of dollars.

We tend to discount sales and marketing personnel, when they are the ones that make your money. They build the brand and they bring the money in, even if you don’t have the best products.

Tim O’Reilly said, “Create more value than you capture.” If you do this your users will love you and your community will grow and support you.

We go into the idea economy and how agile ties into the idea economy. People are trying to sell each other on their ideas in agile as much as anything else.

Andrew was first introduced to Agile he found most of the practices as wasteful, painful, and wrong. So, he started discovering the roots of Agile. What he found was that Agile was bout solving our problems with our strengths. Once he started going to the Agile Round Table, he found that it was actually about delivering working software.

Over the last year and a half, Andrew has been working on taking agile into other areas of work.

The term ‘agile’ has become overloaded. Some people say agile, what most people mean is a watered down half implemented version of scrum.

Agile, the word, has crossed the chasm. The practices haven’t.

Trying to agile isn’t what you should do. You should be trying to be awesome.

Listen to the interview for some great tips on being awesome.

Here are some links to following Andrew:

Twitter: littleidea

Blog: http://stochasticresonance.wordpress.com/

Download this Episode

{ 0 comments }

This episode of the teachmetocode podcast, Dave talks us through the process he and Andy Hunt went through in founding the Pragmatic Programmers book series and publishing company. Dave also talks about the the advantages that they have had by not holding onto or being mired down by the way things have always been done and their growth in non-conventional book selling channels.

He also mentioned that if you would like them to come do training where you’re at, contact Mike Clark and find people who are willing to sit in on the course.

I think my favorite part of the interview was his explanation of where the Agile Manifesto came from. We also got to talk about what Agile development really is.

Dave explains the correlation between his musical interests and his programming interests. He figures that at least 30-40% of speakers at any conference would have some sort of musical background. The structure and the way things come together in music actually applies to software. You create patterns or structures that work well together at multiple levels.

Toward the beginning of the Pragmatic Programmers, Dave and Andy recommend learning a new language every year. He discusses his hobby of picking up new programming languages and investing in yourself.

Finally, I asked Dave about running a business and how to get one started. He gave some terrific advice regarding building your own application and business.

He wrapped up the episode by pointing out that programming is exceptionally hard. You have a huge amount of information you have to know in order to get into programming. On top of it, the world is complicated and makes the problems we have to solve hard. So, ultimately, make it fun!

Download this Episode

{ 16 comments }

This week’s episode on pair programming discusses where you might see pair programming, HashRocket’s pairing setup, perceived and real disadvantages to pair programming, its advantages, and what it takes to do good pairing.

Pair programming is usually associated with Extreme Programming. It is sometimes seen as a mentoring practice, but is actually a collaboration practice, not a mentoring practice. This is because both programmers participate equally, not one leading and the other following for long durations. Pair programming is done with 1 computer and 2 programmers. I’ve never seen it work well with 2 computers and 2 programmers unless one computer was being ignored or under-utilized.
[click to continue…]

{ 2 comments }