Skip to content

Category: refactoringSyndicate content

It's Cool to Break Stuff

May 11, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

I am a proud father of two kids – 5-year old girl and 1.5 years old boy. For the most time they are good kids. But with alarming regularity, every couple of months, they turn out into terrifying monsters. For example, the boy would go to sleep at 7:30 pm each day and sleep well till 7am in the morning. Awesome. And then suddenly he would decide to stay awake for the whole nights for extended periods of time, and his poor parents would of course not sleep as well, turning into walking zombies during the day. Curiously, the little guy does not seem to be tired at all, even after his series of sleepless nights. Or my daughter would one day decide that she no longer likes to eat anything – with the exception of ice cream.

My wife and me used to be disoriented and powerless when this happened – until we consulted a child psychology book that described the phenomenon. And what do you know – not only is such a behavior of a child expected and normal – it is essential for the kid's development! Kids have to break the rules regularly, in order to build something new on top of the rubble.

By now, you can probably tell where I am going with this extended tale of my family life: the same rules apply to the software project. Every once in a while – and regularly – break something and re-fix it in a new way. Otherwise, your project, its internal architecture, its priorities, its target audience, its feature set, will petrify and very soon cease to be useful, attractive and desired.

Refactoring in action

July 24, 2008 by Przemysław Bielicki

Quite recently I attended my company's internal presentation regarding agile software development (ASD). During Q&A (questions and answers) part someone who was not convinced to use ASD complained that refactoring means rewriting the code from scratch. It's bullshit, of course, but as you can see people who don't know ASD can proliferate misconceptions about many ASD ideas.

In this post I would like to show you an example of refactoring in an unconventional way. I hope you will like it.

The Fruits of Pain

July 15, 2008 by JurgenAppelo

Pain I recently blogged about a little personal disaster that resulted in 100 gigabytes of data being wiped out from both my hard disk and my backup disk. Fortunately, I was able to recover most of the important data that I lost. And despite the panic of the moment I can say that I might even be better off now.

The situation after the catastrophe is better than the one before.

Reconstructing my data folders required me to rethink the folder hierarchy, to clean up old junk I never used, to improve file and folder naming, and to clearly separate vital data from convenient data. Before the crash my data storage situation was a bit messy. It wasn't bad, but it just wasn't good either. But after the catastrophe I spent a lot of time creating a situation that is now much better than before. So, why didn't I do all of that earlier? It would have saved me a lot of trouble.

Refactoring tool requirements

March 26, 2007 by Artem

In four days after the desires for the agile-aware C++ IDE were posted on AgileSoftwareDevelopment.com, Michael Feathers, the author of "Working Effectively with Legacy Code" posted his own set of the refactoring-related requirements for the IDE.

Have a look

Agile-aware C++ IDE

March 9, 2007 by Artem Marchenko

A colleague of mine lately asked me what would be the most important C++ IDE features for supporting the agile software development. While agile processes are more about people and interaction, than about the tools, a decent tool support certainly makes things easier. Here is a list of things I would value in the agile-aware C++ IDE in the order of decreasing priority.

1. Command-line repeatability
Agile methods see the high levels of automation of a ‘mechanical’ and repetitive tasks as a relief for the developers and help to reduce errors.


Costs of the legacy code

November 7, 2006 by Artem

"To me legacy code is simply code without tests."
Michael C. Feathers “Working effectively with legacy code”

The legacy code is a known software developers’ headache. The legacy code is the difficult to change code that the developers don’t really understand. This code often is inherited from the old developers who left the company, it usually has little to no documentation and little to no testing code. Legacy code can slow down the development speed up to the real competitive problems. When it takes eternity to make a required change, a company can hardly stand a competitor that is able to release life-critical software every month.

Best of AgileSoftwareDevelopment.com