Jan 29

Are your zombie memes killing you?

tips No Comments »

Anybody here ever seen a zombie flick? Well then, we all know what a zombie is, but what is a zombie meme? Read on for more.

What is a meme?

For that we need to refer to Richard Dawkins and his book The Selfish Gene. He makes the parallel between a human gene and a unit of culture, which he termed a meme. I’m using culture here in it’s social sense to mean a collection of ideas that shapes our actions that is common to our society. There are a lot of interesting parallels that cross over between the genome based view of biological systems, and the memetic view of cultural systems.

For example, our genes use us to replicate. Therefore genes compete with other genes (in other humans) to ensure their continued replication. One strategy is to introduce characteristics in their host that promote the end result of successful replication. This is the basis of evolution and the continued survival of the most fit organism for their environment.

Memes compete with each other by taking up space in our culture, which essentially means our awareness. They can be as simple as knowing that an iPod can be used to play music, or as complex as a natural language. To be successful a meme must replicate, and there are many strategies to help it do so. The “put wheels on a sledge to make a wagon” meme was successful in creating the automobile industry because it was immediately obvious to anyone looking at a wagon how to build it. The manifestation of the meme (the wagon) was replicated, and so the meme was able to leverage this to create many more copies of itself than the original item. More people know about wagons than own one.

So a zombie meme is…?

One that no longer serves a useful purpose and is simply getting replicated for the sake of it. People simply adopt the zombie meme as “best practice” without question and mindlessly repeat the instructions regardless of how damaging those instructions are.

Examples of this include wasteful business practices:

“Can you print that email for my records?”
“We only take orders by fax, then we type them into our computer system. Hope you’ve got good handwriting.”
“Please read the 50 page guide before filling out this form.”

or software development methodologies:

“Code around it quick, we’ll get the users to test it.”
“We design, code, test and ship. In that order. Once.”
“We don’t use XP, we use Scrum.”

Hang on – did you just have a go at Scrum?

Indirectly, yes. Scrum is the prevailing Agile implementation and there are a lot of excellent reasons to use it. However, simply using a particular methodology without fully understanding what type of development environment it is targeted at is essentially allowing a zombie meme to infiltrate and replicate.

But everyone does Scrum so it must be the best, I hear you mutter. Not necessarily. Consider the article Flaccid Scrum by Martin Fowler where excited project managers pick up on the Scrum process. All is well for a while then the project slams into a brick wall due to overwhelming technical difficulties caused by a legacy code base. This isn’t Scrum’s fault, you need to have good technical practices in place before Scrum will show it’s many advantages. A better choice in this scenario would be XP with all it’s technical recommendations.

Another scenario is that the nature of the work doesn’t lend itself to a constantly changing work load, such as maintenance programming or rapid response to a fickle client. Some changes take a day, others a week or so. Scrum relies on a clear stretch of time to accomplish the work, whereas Kanban provides a much more flexible approach.

And what if the project involves a dual-shore development team, operating in different time zones? It may be better to adopt the Stride approach (PDF), which is based on Scrum but tailored for separated teams.

As I mentioned earlier, memes replicate, but they also mutate leading to a conflation of ideas that can in turn lead to a better fit. Such is the case with a group of people who are now trying to blend Scrum with Kanban to find an even more efficient and flexible development process.

There are interesting times ahead, and not a zombie in sight.

Share
Tagged with: • • • •
Jan 27

7 refactorings I couldn’t live without

tips No Comments »

As a full time developer I spend a lot of time writing code. And I almost never get it right first time. I did once, a long time ago, and since then I’ve not had such luck so I’ve had to rely on a myriad of safety nets, such as unit tests and a keep it simple approach to design. Even then my code tends to grow somewhat organically leading to various code smells that a healthy wave of refactoring wafts away.

I thought I’d take this opportunity to share the ones I use the most often – in fact I couldn’t really live without them these days.

1) Rename and Change Method Signature

My personal favourites. Rename does just what it says on the tin. Initiate the refactoring, tell the IDE to apply it in all the right places and it just does it. When applied to fields in Java beans, the IDE will ask if sir would like those getters/setters renamed as well, and throughout the application, including JSPs. Yes, please, do that for me and save me a whole bunch of time.

Change Method Signature is even better because it includes Rename as a happy side effect. Want to change the order of those parameters and their types but don’t want to screw up all the myriad of calls into those methods? Why, yes, yes I do, Mr IDE. Just click in this box until you’re happy with the new order and let me do all the hard work. Don’t mind if I do (cracks open beer).

2) Extract Method

Especially useful when exploring a new code base. If you want to simplify a method that has clearly gotten out of hand, just select the area you feel should be a method in it’s own right and hit that refactor button. Suddenly all that complex code is whisked away and in it’s place is a simple method call. And if your IDE is really spiffy then you’ll find that all the other copy/pasted versions of that code have also been refactored into the method call. Marvellous.

3) Pull Up and Push Down

Have you suddenly discovered that a method or field is going to be duplicated in a bunch of subclasses? Use Pull Up to move the duplicated method or field into a super class. Done correctly, the IDE will automatically apply the refactoring to all subclasses with the duplication and substitute the super class reference in it’s place.

Push Down, as it’s name suggests, does the opposite. Your wonderful base class is now preventing subclasses from specialising as they should so you push the field or method down so that the subclasses can implement the method or not as they see fit.

4) Extract Base Class

Want to do a Pull Up but don’t have a super class in place? No problem, just use this and select the methods/fields that you want pulled up. Want that base class abstract? Not a problem, just tick the box, sir.

5) Introduce Parameter Object

If there’s one thing I really hate it’s a method with a long parameter list. And by long I mean 5 parameters maximum. Especially if they’re all named string1, string2, stringX and so on because a) it’s mental, 2) it’s confusing and iii) nobody will ever get the parameters in the correct order.

The solution to this debacle is, of course, to introduce a parameter object. A simple Value Object (read Java Bean) that abstracts all the parameters away behind a single reference. Want to add a new parameter but don’t want to have to go and change all the method signatures on your publicly available API? Just make sure they take a parameter object and the API will continue to work as you change the properties on the parameter object. If you were feeling really ambitious you could put validation code into the parameter object to provide a defensive layer, but that’s just silly, isn’t it? Isn’t it?

6) Introduce Constant

We’ve all done it: hard coded a string or number somewhere. Then used it again. And again. Then realised that, really, it should be defined properly somewhere up in the root of the class or ideally injected. And that is exactly what the Introduce Constant refactoring does. With a swift click of the mouse all the duplications are pulled up into a single, well named constant field destined to remain the single point of reference for that datum for all time. Very DRY.

7) Introduce Field

Method signatures getting a bit repetitive with that same reference getting passed around all over the place? It’s about time that parameter was converted into a fully fledged field.

The only problem with refactoring is that after you’ve done it a few times you kind of get addicted to it. Before long you’ll be spotting duplications and excessive parameter lists all over the place and applying refactorings to tidy them all up and what are you left with? Just well designed, clean code that is much easier to maintain.

Share
Tagged with: •
Jan 14

9 top tips to understand new code

tips 3 Comments »

9 top tips to understand new code

You’ve just started at a new company, or have been introduced to a new system,  and you need to get up to speed quickly. Here are some proven tips and techniques to get you started.

1) Show no fear

Most developers are nervous when they first encounter a new system, but just keep in mind that it’s only code. There is a structure involved, however convoluted and apparently incomprehensible it may appear at the start. Once you start exploring this new realm of code you’ll be able to gain greater understanding, and if you’re the only one who knows it then your position within the company becomes much more valuable.

2) Identify the principal technologies involved

Have a quick scan over a few modules in the system. If you recognise various patterns that indicate classic design approaches (e.g. Spring, EJB, OSGI, Hibernate) then you’re in luck – you can make rapid progress. If not, then don’t despair. It just means you have to do some reading. And if you don’t do the background reading then you’ll be floundering in no time trying to wrap your head around a seemingly incomprehensible approach to coding. However, investing that time in yourself will mean that you’ll recognise patterns and will be able to start making progress.

3) Leave breadcrumbs for yourself

As you step into the code and start exploring the dependencies among the various objects it is important to build up a trail of breadcrumbs to help you find your way back. Just keep a list of class names with a short note of what they apparently do, along with some notes on possible future refactorings . Perhaps some simple diagrams here and there. They don’t have to be a full-on UML representation, just a quick scribble in your notebook is sufficient to understand data flow and immediate class dependencies.

4) Add comments

As you go through the code add comments so that you leave the system in better shape than you found it. The next developer to follow in your footsteps will definitely thank you for it – so long as the comments are accurate and to the point. Don’t comment the obvious: “Setting km to 111″ is redundant – any developer can see that. Instead, reserve comments for the less obvious: “Using an approximate value for kilometres in a degree of latitude – REFACTOR with method?”. This identifies the overall context of the value, and raises the possibility that a method could be employed to return differing values depending on the longitude.

5) Explore the database

Nearly all applications attempt to model their database in some manner, and the database is usually the cleanest part of a system. After all, the database is likely to be reasonably relational in nature and there are a lot of tools available to allow exploration of a schema visually. By exploring the database the principal entities involved in the system can be identified and this in turn provides some insight to starting points within the code. Of course, if the database is a mess, imagine how awful the code that relies on it is likely to be.

6) How does login work?

Almost every system has some kind of login process and since this does not vary an awful lot conceptually it provides a good starting point. In understanding the login process you will have a better idea of how data is taken from the user interface and the database; compared in some kind of business logic and how the result is output to the user interface.

7) Write a test

Once you feel confident navigating around the code base, the next step is to try to add some code. The safest way to do this is to write some code that will never get released to live, but serves a useful purpose: a unit test. Pick a class that has few dependencies and then write the unit test. Do not alter the class under test. Your objective here is not to rewrite the existing code, just to understand how to introduce the unit test framework, or use the existing one.

8) Implement a small change

Pick an innocent looking change from the task list. Ideally, this should be something straightforward like a user interface correction or a small extension to existing code. Then implement it in very small increments, with a unit test covering your efforts as you go. Do not make big sweeping code changes, or refactorings that affect a large number of dependencies. Keep it small. Keep it simple.

9) Break dependencies

Once you’ve got some confidence with the code and you understand (somewhat vaguely) how it all hangs together, then it’s time to identify and break dependencies. This means finding a way to break tightly coupled code into smaller fragments that provide better encapsulation. Usually this means following a dependency injection (or Inversion of Control) design pattern. There are several available refactorings that help with this: Encapsulate Field; Extract Method; Extract Interface; Extract Subclass; Extract Superclass and so on.

Share
Tagged with: • •

You should follow me on TwitterYou should follow me on Twiiter here.

preload preload preload