Agile Zone is brought to you in partnership with:

Isaac Taylor is an aspiring mobile developer and a technology geek. He spends most of his development time finding kinks in developing apps and mobile web sites for Android, iOS and Windows Phone 7, and he posts the solutions so you don't have to. When not developing software himself, he's likely reading about how to write better code. Isaac is a DZone MVB and is not an employee of DZone and has posted 11 posts at DZone. You can read more from them at their website. View Full User Profile

Coding for the Changes You'll Have to Make Next Month

  • submit to reddit

One of the most difficult parts of software development is adapting to change. It's a guarantee that the concepts, ideas, and possibly the point of the program that you are writing will change several times before it's actually done.

If you have ever heard the buzzwords like Agile, Scrum, Extreme Programming, or anything similar, then you have put some time into writing software that adapts to change. Any programmer serious about the craft has at least heard about it, but few have actually mastered it (and neither have I). Designing a program that easily adapts to change is a very difficult task. However, there are a few good ideas I have found that help create this kind of software at a team level:

  • Spend more time on design! Seriously, spend a few days or weeks on it. Time put into simply designing the software and not touching the code itself is time well spent. The better your design, the less pain will come your way down the road when the product is getting ready to ship.
  • Think about what type of changes could come in the future. What would need to change in the system to let these new features exists? The smaller the effect on the entire system, the better.
  • Step back from the requirements of the system for a moment and ask yourself why the system is designed in a particular way.
  • What is going to happen when you run out of time (which you will)? Where do you think shortcuts will be made?
After designing a system, spend a few days (yes, days) thinking about possible additions to the system. Don't just rush into coding up the system after you have one working solution. With these ideas, think about how the system would have to change to accommodate this new idea. It really doesn't matter if these additions are realistic, feasible, or something that no one would really want in the program. If it's difficult to add to the current system, then maybe the system should be redesigned to accommodate it.

The other trick is really just refactoring-- but taking it to the extreme. Any and every chance to refactor some code to make it more readable, useable, and simpler, should be taken. Don't let confusing, complicated code stick around in the code base just because you have more important things to do, or you didn't code it yourself. If the code doesn't make sense or is difficult to understand, get with the programmer who wrote it, and make it simpler. At the very least, understand what caused the code to become so complex and avoid that path next time. You'll save yourself a ton of time in the long run of the project, and by making the code simpler, it will be much easier to change later on.

"Anytime you find yourself looking at a class's implementation to figure out how to use the class, you're not programming to the interface, you're programming through the interface to the implementation. If you're programming through the interface, encapsulation is broken, and once encapsulation starts to break down, abstraction won't be too far behind."[1] 

Basically, this quote says if you have to look how a class/method/function works to figure it out, you're doing it wrong. Proper design hides this information well so that once it's written, it can be taken for granted. This is an excellent time to refactor and think about how the code really should be structured.

What ideas and concepts do you use to create adaptable software?


Published at DZone with permission of Isaac Taylor, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Eyal Golan replied on Wed, 2013/04/17 - 8:10am

I can't agree with most of your comments.

In agile approach, you basically develop for the current requieremnts, as you can't tell what will be in the future.

So, "...Think about what type of changes could come in the future..." is the opposite of agile.

"Where do you think shortcuts will be made?" - well, I believe shortcuts should never be made. In my experience, when you try doing a shortcut, you will probably end with more time consumption fixing some bugs. Do not make shortcuts !

"...spend a few days (yes, days) thinking about possible additions to the system...."

Again, this is not the agile approach.

What I am saying here, is not that you should not design prior to code. And I'm not saying that you should not think ahead.

But you can't predict the future. You described some kind of waterfall approach.

When talking about 'adapt to change' in coding. I think that it means that you should design and implement the code so that you will be able to extent it.

I agree that you should code using interfaces and not implementations.

So, design you system so it could be changed easily, but remember, you can't predict the future so you can't know what will change.

Have a look at: open closed principle 

Hikari Shidou replied on Wed, 2013/04/17 - 7:49pm

 You ideas seem kinda utopic.

Best practices today say to start developing early. It's just not worthy cracking your head trying to better understand the business before coding, just because we have limits on how much usable abstraction we can imagine without feeling in reality how it looks.

Isn't really there NOTHING you already understand that you can't implement? If not, just prototype to have something tangible. Keeping building designs and writing text won't move you anywhere other then theories.

Also, remember that if you feel like trying to understand the whole business before constructing, you'll fall on waterfall process!

And if you keep thinking in the future, you'll lose track of present. You'll keep trying to get solutions for problems you don't even have yet, and risk not seeing the problems you didn't expect in the past and are here right now.

How to handle changes? Just build a bood architecture, keep everything clean. Use encapsulation and interfaces everywhere. Good interfaces. Practice Loose Coupling. Test with intelligence and efficience. Effective tests. Reuse, modularize. This way you'll have a good quality software and will be able to change what's needed, when really needed, without having to change it all.

Lund Wolfe replied on Sun, 2013/04/21 - 5:57pm

XP's YAGNI says don't add to the design complexity by trying to predict the future, because we're not very good at it.

Obviously you understand KISS and the importance of refactoring, especially early in the process.  Totally agree with spending plenty of time on a good and simple design.  You can't afford to get this wrong any more than getting the requirements/analysis wrong.  If you know real customer requested requirements/enhancements are coming, then you do need to factor that into the design or you risk breaking (or hacking/kluging) your overly simple design later.  It's a compromise/judgement call in doing a minimum of complexity and effort to satisfy those future requirements, which may never come.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.