Marko Anastasov wrote this on November 29, 2011

Agile and change

It happens that people identify themselves with a piece of work that they did. From a purely logical perspective, this does not make any sense, and generally it is a guaranteed way to lose your personal tranquility. Yet it’s sometimes difficult to control, especially if you don’t practice it somehow.

To a programmer it may occur on both code and feature level. You think that something is such a great piece of code that it’s a pity to remove it. The more time you’ve spent on it, the greater the feeling. It influences your thinking in a situation when you’re asked to discuss the real user value of it.

That’s one aspect where agile shines. When you’re writing a spec first, that flow has framed the implementation code for you differently. It is more like a means to an end - to make the nice test pass. And that’s good because your code is a means to a user’s end. So you’re not personally attached to it.

And when you’re collaborating with your client daily, he gets to see the direction where you’re going with a larger feature when it’s 20% done and not 99% done. It’s a great framework of collaboration where nobody is afraid or opposed to change for any reason. Indeed, you will embrace change, as change is natural and feel a boost every time you refine your creation to better match the product.

comments powered by Disqus

About Marko Anastasov

Rendered Text co-founder. Started with code, currently more focused on people and words. Foosball striker and entry-level cyclist.

Suggested Reads

Rails Testing Handbook

A new ebook on building test-driven Rails apps with RSpec and Cucumber.

At Rendered Text, we have a long history with Ruby on Rails. Checking the blog archive reminds me that we published first posts about working with Rails way back in 2009.

———

Rendered Text is a software company. For questions regarding Semaphore, please visit semaphoreci.com. Otherwise, feel free to get in touch any time by sending us an email.