What IS students are saying about Philip Laureano’s Refactoring Workshop:

“…can this be an alternative class? sayang kasi….you will really learn a lot in this seminar… sana required ang IS students to attend this =( …we must grab the opporunity.” – Jecca Cervero

“…in this seminar, you will learn a lot of things especially about refactoring the code, it will be a great help to a lot of IS students ..I think it should be required!” – Marjorie Buce

“… coding has never been this simple, I now see and write codes from a different angle. This workshop has taught me beyond what I can learn in my programming subjects, such as time management, simplicity and code readability. If it wasn’t for this, I would still have a hard time reading and maintaining codes, even my own.” - Tish Mahtani

“… I’m not really into coding or programming stuffs. That’s why I attended this event to help me gain more knowledge about programming. What I liked most is being able to shorten heavy weight of codes into a very short and readable ones.” – DK Abrenica

“.. the first rule of programming is not to program at all! This seminar taught me the virtue of simplicity and cleanliness in code writing; it surely was a great headstart into the very cumbersome software development field that we IS students are to undertake in the near future. The opportunity of learning from one of the best senior developers and programming mentors in the country lead me to into realizing that the practice of coding need not be so complicated, that the best way is to simplify. Less is more!” – Uij Dollosa

“… When I see codes that are alike, I just usually copy and then paste it. But, does it make me a good programmer? Of course not! It also makes me unprofessional. Good thing, refactoring helps a lot. It makes my codes short, simple, easier to maintain and organized. In addition, I could be proud that I don’t do copy and paste When I learned about refactoring, I realized that I don’t have to make myself not love programming due to tons of confusing code lines and time consuming editing the whole program, because there’s a more easy way to understand and do it ” – Jill Montano

An interview with Refactoring Guru, Philip Laureano, of CodeLean

Last November 14, 21, 28 and December 8, the Association of Information Management hosted a refactoring workshop for DLS-CSB students and alumni conducted by BSBA-CA Alumni, Philip Laureano, who is now a Technology Evangelist from CodeLean. Here’s an interview by Paul Pajo, faculty adviser of AIM about refactoring.

Paul Pajo: From a non-IT person’s point of view, what is code refactoring?

Philip Laureano: Refactoring is the part of a programmer’s job that they never teach you in school. Universities usually teach you how to build software like an engineer, but they don’t teach you how to maintain it once the software is built. In software development, we’re faced with impossible scenarios every day. We’re given deadlines, requirements, and schedules that change on a daily basis. Building the software is only 10% of the overall work involved. The other 90% of the work that is done by software developers is making sure that their applications are flexible enough to meet these seemingly impossible requirements It’s like having a professor who changes their mind every day, and holds you responsible if you’re unable to meet their requirements (no matter how unreasonable they might be). It’s not enough to build the software–you have to actively maintain it so that you’ll be ready to change it once the next requirement comes in

Paul Pajo: So where does or how does refactoring come into play?

Philip Laureano: Refactoring is the art of reorganizing your code so that it’s easier to change, maintain, and understand. This isn’t some new technology–it’s been around for almost four decades now. If you’re a software developer with at least four or five years of experience under your belt, there’s a good chance that you already do this but you probably never thought about it

Paul Pajo: It wasn’t called “refactoring” until fairly recently, was it?

Philip Laureano: I believe it’s been called that for four decades now. Actually, it’s been done for four decades but it really didn’t get much attention until Martin Fowler wrote his book on Refactoring.

Paul Pajo: Okay so, from your experience, why should students or even junior programmers learn refactoring from the get go?

Philip Laureano: It will give them an advantage that many people of their skill level rarely attain. It takes years to learn this stuff. Refactoring is about learning how to improve the quality of the code that you already have. It’s learning how to reshape your software in such a way that you can move faster than the competition because of the quality of your code. I would even say that refactoring should be as natural for a programmer as naturally as a doctor washes his hands before an operation. And from another standpoint, you really don’t get much peer respect from other programmers if you write code that is not refactored. So on one hand, it makes your job as a programmer much easier to do since refactoring makes your code easy to maintain. On the other hand, no programmer would want to work with you unless you can show them that the code you write is clean

Paul Pajo: Am I correct to say that the refactoring workshop you did in CSB is the one of the first if not the first refactoring workshop in the Philippines?

Philip Laureano: Yes, that’s correct. We wanted to see how it would affect people with some rudimentary programming experience. It was a mixed experience, but overall, I’d say the students learned quite a bit from the course.

Paul Pajo: Okay, this begs the question, if refactoring has been around for almost 4 decades and it’s such an important part of programming – why only now?

Philip Laureano: It’s because for the first few decades in software development, the focus has been solely on delivery and construction. But over the past ten years or so, we (as an industry) are slowly starting to realize that our problems are caused by the cost of maintenance, not the cost of construction. So you can come up with the most magnificent specification for software, but it quickly becomes obsolete when the next set of requirements come in and you can’t change your code fast enough to meet those requirements. Big Design Up Front (BDUF), in essence, is practically ineffective

Paul Pajo: There was a Red-Green Refactor: Test-Driven Development with .NET back in October 5 2006 – how is that different from what you’re doing?

Philip Laureano: I focus on the “Refactoring” part. You can’t do TDD without refactoring, and vice-versa. TDD helps you write testable code, but it’s the refactoring part that lets you improve the design of the code that you have already written. In fact, it’s pointless to show people what TDD does if they can’t refactor. They need to understand why their code needs to be clean; otherwise TDD can get messy and very, very, ugly. TDD’s basic concept is that you write the tests first, make the tests pass with the simplest (and even ugliest) code possible, and then you take the “ugliness” out of the code. It’s basically an introductory course. I assume that he doesn’t cover refactoring because it’s either too big of a subject to discuss or perhaps he thinks that enough people know how to refactor their code

Paul Pajo: I searched devpinoy.com – you’re right – refactor seminars/workshops are scarce.

Philip Laureano: You’d be lucky to find a single refactoring course within all of Southeast Asia.

Paul Pajo: How is technical debt related to refactoring and could you explain in layman’s terms what technical debt is?

Philip Laureano: In layman’s terms, technical debt is the kind of debt that you get into when you decide to skip critical development activities in favor of a shorter release cycle. It can be anything from deciding not to refactor or opting not to document everything because you think it takes too much of your time. Like any debt, you’ll eventually have to pay it back; otherwise, your productivity will eventually be crippled by that debt, and you won’t be able to work as efficiently as you did beforehand.

Paul Pajo: So from your experience, how much of a technical debt can be avoided if you refactor from the start?

Philip Laureano: All of it. It takes a lot of discipline, but you can pretty much cut your maintenance work to zero if you keep refactoring early. That’s what we have done with our projects at CodeLean.

Paul Pajo: And you’re saying this from experience? Can you compare your programming experience before and after you became disciplined in refactoring?

Philip Laureano: Yes, I’m saying this from experience. Back in 1999, when I was just starting out as a programmer, I didn’t know what refactoring was, nor did I understand how much the quality of my code had a huge impact on my own job performance. And now, in 2009, after working on dozens of both closed and open source projects, I’d say that refactoring has made my job really easy. I never have to spend more than an hour maintaining my code. Other shops typically would have entire teams looking through thousands of lines of source code to fix a bug. We keep our code so clean that we can spot the bug immediately and fix it. At first, refactoring didn’t make much sense to me–but it made a huge difference when I realized that I spent less and less time on maintenance because of refactoring. It also keeps our developers happy since we never get any complaints about ugly code. It just all works.

Paul Pajo: Can you go back to that “Eureka” moment? Was that a factor in you deciding to be a refactoring evangelist?

Philip Laureano: It wasn’t a “eureka” moment as much as a moment of frustration. I cared deeply about writing good software (even back then), and I couldn’t understand why people didn’t see anything wrong with their code when they decided to “Cut & Paste” it a dozen times over because they didn’t understand the concept of loops. I ran into so many cases where we had to stay overnight and fix a bug that was caused by a programmer who wrote ugly code. So I’ve become a big proponent of refactoring simply because teaching it to other people saves me the headache of having to clean up their code. At the same time, you really can’t get much respect among your peers if you don’t write clean code. Maintaining code is probably one of the most challenging parts about working as a programmer

Paul Pajo: So what exactly do you do now? From what I’ve gathered, it seems to be your dream job. Is this correct?

Philip Laureano: It is my dream job. I started off as a lead developer and CodeLean told me that they needed someone to help them get their shop set up with the best coding practices. So for the first six months, we got everyone setup with TDD, Continuous Integration, Refactoring, and Automated Web Acceptance Testing. Once we were done with the setup, CodeLean decided to focus more on training other developers. Now, I’m going to be a trainer/evangelist. So my job is to write articles, develop my personal projects, and promote the company’s courses with my blog posts and technical articles. It’s a dream come true for me because I get paid to do something I already do as a hobby.

Paul Pajo: That’s awesome! Any last words for students and programmers who might be interested in refactoring?

Philip Laureano: If you’re serious about being a good developer, then you must learn refactoring. It’s a critical skill that determines whether or not you’re a real programmer, or if you’re just someone that happens to write code. Any code monkey can write a program, but it takes a real human to write readable code for other humans. If you want to stand out as a programmer and be counted among the humans, then you definitely need to refactor your code. Always.

If you want to contact Philip Laureano about refactoring and other code-related matters, follow him on twitter.com/philiplaureano