Adicionei no projeto Refactoring-scripts um novo script: o remove-temps. Ele apenas busca recursivamente em um diretório por arquivos temporários e os elimina. Como é útil rodar antes de comitar, adicionei a opção -g, ou –git, que executa o comando “git rm” para todos os arquivos temporários, sendo que para utilizar esta opção, deve-se estar na diretório root do projeto e os arquivos ainda devem existir.

[]’s

Tip #24 – Identify common behavior and encapsulate it

Looking for common behavior across classes is an effective way to reuse behavior. When you find yourself cutting and pasting code, take a step back and reflect on the common behavior that is being implemented. If the duplication is due to the same behavior realized in different ways, introduce a new interface. If multiple objects have the same functionality and can derive from a parent object, introduce an inheritance hierarchy.

This can be done in an iterative fashion as well – if you failed to recognize an interface initially that is okay. Look for opportunities to refactor existing code to introduce a new interface. For example, you can use the Eclipse IDE’s refactoring feature – extract interface – to create a new interface from an existing class.

Why is this important for systematic reuse? Because, by isolating and realizing common behavior you reduce the need for multiple components and classes to re-implement the same functionality. If two classes need the same piece of data, or if they both connect with the same external system, why would you want to code them separately?

Like this post? Subscribe to RSS feed or get blog updates via email.

My last Agile Revelations post was an unexpected foray into the reasons behind why I love Agile so much. Written on a Friday night, a bit bored, it started me thinking about my career in software development and how I got to this point in my life.

So if you weren’t put off by my previous post and are still interested in what motivates people like me to pursue this most rewarding of methodologies then read on……..

So where was I? Oh yes, I was still in my first development job and I’d just finished reading Extreme Programming: embrace change by Kent Beck – the book which single-handedly inspired me to take on Agile. I’d been in that role for about a year by the time I finished the book and at around the same time I completed my full MCSD in my spare time. And it was lucky because within a month my company had no more C# work for me (they’d decided to re-write in java) so I took a junior C# developer role with a new company.

The development work there was challenging for a relatively in-experienced developer so I found it hard work implementing real WinForms and ASP.Net Web applications into production, but the hardest thing about it was that between projects there was a lot of “sitting around time” where we would be waiting for work (read spec documents as it was a classic waterfall environment!). This was so immensely painful as I hate being bored, having to pester people to give me work to do so in the end I used this time to improve my development skills and learn more about Agile.

The funny thing is that nowadays “being Agile” is such a buzz word and everybody and his dog is claiming that their company is doing it. But at the time it still felt very new (well I guess it was in the UK) and it wasn’t enough to just read buzz word books about XP – I wanted to learn the coding principles behind Agile and understand what made these programmers (apparently) so talented.

So I spent loads of time reading blogs, researching who was saying the most about Agile and XP and (to name but a few) I came up with some very well known writers on these subjects: Martin Fowler, Kent Beck and my own personal God Jeremy Miller.

I quickly realised that an Agile methodogy is useless if you don’t know how to write quality code so I started buying books which concentrated on improving development skills and writing clean code, here are just a few I started out with:

Refactoring by Martin Fowler
Test Driven Development by Kent Beck
POEAA by Martin Fowler
Head first Design Patterns by the Freemans
Applying DDD by Jimmy Nilsson

And that was how I spent my 2nd year in software development. It was an interesting time and for anyone just starting out I would definitely recommend these writers (and obviously a whole load more now – you’ll have to wait for part 3 for those!). The only caveat I would say is that these guys are so good that I did sometimes feel out of my depth, thinking I would never be able to write code as well as them (which is probably still true but I do at least now try!). I think this was probably a very natural reaction but to counter it I would recommend that rather than just reading about the concepts, try to implement them as often as you can in production code. With that said, the best way to ultimately learn is to find an environment with technically excellent, like minded people, eager to learn the same values and able to implement them in production.

Enter uSwitch stage left

Until next time…

Sometimes a design will arrive for an everyday item that’s so blindingly obvious yet revolutionary you have to wonder why nobody did it before.

Such a design is the folding plug, designed by Min-kyu Choi.

Taking inspiration from the Apple Macbook Air, which is advertised as being the ‘world’s thinnest laptop’, Min-kyu found irony in the fact that this wonder of modern design was saddled with the rather archaic and clunky UK three-pin plug:

In a breathtakingly simple but inspired design, Min-kyu has created a clever folding plug which occupies under 1/3 of the space of a conventional UK plug.  Thinner than your little finger when folded, this beautiful bit of design refactoring takes plug design forward in leaps and bounds:

As software designers, we should be actively seeking out the ‘chunky plugs’ in our world – awkward, unfriendly, approaches to interaction that have somehow become the ‘norm’.  These are the things that people put up with despite their shortcomings.  If we put the effort in, we shall and will find them.  We may even be able to come up with something significantly better.

Min-kyu deserves great credit and recognition for making such an improvement to an everyday object.  I hope that you can find your own ‘chunky plug’ and make your own mark.  After all, that’s the essence of good design – improving our everyday lives.

Recently I wrote about some of the Really Big Cool Commercial Things people tried to do on the Internet when it was still kind of a fad. These Big Things tended not to work out either because they didn’t make sense to begin with, or because their perpetrators could never settle for something that actually worked and delivered value.

I think (and said then) that this is probably because people often enter into business for reasons other than doing stuff that works and delivers value. If, on the other hand, you *cough* do stuff that works and delivers value it’s a lot more likely your business will do well. Notably, it doesn’t have to have an amazing idea behind it.

My favorite example of this is those nifty little PC-based cash registers. I’m a bit out of date on who has what these days, but back in the early and middle 1990s it seemed like one out of four mall stores had something from Systems for Today’s Retailer, which went by STR most of the time when I worked there.

STR started a little like this. Scott and Chuck what I call a dumb idea: to mimic those $10,000 intelligent cash registers that know how much everything costs, calculate discounts, print time cards, keep inventory up to date, and send sales data back to the corporate offices. Except they would do it for around $3,000 on an industry-standard PC.

That’s all. That was the big idea.

I’m sorry, there just isn’t very much to it.

It hit big. Everyone wanted this. They made their first sale to a small chain of jewelry stores headquartered in California. Then there were a couple of local Ohio customers. A place that sold swimming pool supplies, stuff like that. There was a chain of pet supply stores. And a nascent chain of computer superstores. None of these were gigantic wins, but they were mostly solid customers who paid a fair price for a good product.

Hey, there were a lot of problems with the software. By the time I showed up as the fifth employee, Scott’s office contained a clear box of 5.25″ floppy diskettes, generally three for the uniquely copied source code for each client’s custom applications. “Source control” was pulling things out of the box and putting them back.

What we considered the “base” application was about 160,000 lines of Clipper code, largely cut and paste from previous versions. In fact, one of my first really big refactorings involved merging eleven slightly different versions of the main item entry function into one, with just a little branching to distinguish the eleven kinds of transactions. It wasn’t the best code base to work with.

But it didn’t matter, not then, not really.

The key thing Scott and Chuck did, and this was seriously brilliant, was to figure out what people wanted to pay money for and making it work well enough to use. (Well, that and hiring me.) In a few years, STR had become fairly stable and rather profitable. We had matching 401(k) plans and good health insurance. It was a good place to work, and the software itself got quite a bit better as we improved our code and project management practices.

I started working with those guys almost twenty years ago now, and I still keep thinking… wow, it’s just a cash register with a regular computer in it. That’s all.

What’s the difference between a Great Idea and a Great Business?

One is fun to think about. The other is a lot of hard work.

And what do you know, tonight begins Startup Weekend Cleveland. In about five hours, I’m going to join about seventy other business and technical people to talk about ideas, pick a subset that the group will develop into products, and personally contribute to one of those. Which ones will be most successful? I’m betting on the ideas that make people say “I need that!” not “Oh cool!” In other words, the stuff that works and creates value.

This is probably the cleanest CS11 code I have ever seen:

main(void){
  load_file();
  interface();
  return 0;
}
// method definitions here

It’s a Pokedex program in C. This one got a really high grade I heard but best of all, it’s just so clean — although its stack call can tend to grow.

I’d like to say that this gave me insight on how to clean my CS180mp. Which before I saw this, my main method looked like this:

public class Runner {
	private static final String EXIT = "-1";
	public static void main(String args[]){

		Scanner scanner = new Scanner(System.in);
		String input;
		double learningRate;
		int maxEpochs;

		while (true){
			printWhatFunctionToLearn();
			input=scanner.next();
			if (input.equals(EXIT)) break;
			BooleanFunction functionToLearn = functionToLearn(input);

			System.out.println("learning rate?");
			input=scanner.next();
			if (input.equals(EXIT)) break;
			learningRate = Double.parseDouble(input);

			System.out.println("maximum epochs?");
			input=scanner.next();
			if (input.equals(EXIT)) break;
			maxEpochs = Integer.parseInt(input);

			Perceptron p = new Perceptron(learningRate,maxEpochs);
			p.setTrainingExamples(new Input(0,0),new Input(0,1),
					new Input(1,0),new Input(1,1));
			p.setFunctionToLearn(functionToLearn);
			p.initializeWeights();
			p.learn();
			p.seeLearningResults();
		}
	}

Using the technique the kid did in his code and applying it to mine:

public class Runner {
  public static void main(String args[]){
     while (true) {
        displayMenu();
        Input input = getInput();
        Perceptron p
          = new Perceptron(input.getLearningRate(),maxEpochs);
        p.setTrainingExamples(new Input(0,0),new Input(0,1),
	   new Input(1,0),new Input(1,1))
        p.setFunctionToLearn(input.getFunctionToLearn());
        p.initializeWeights();
        p.learn();
        if (input==NULL) break;
   }
}
}

Poof! I go from 34 lines to 15 readable lines! I have reduced my code to half and it still behaves the same way. Now, I don’t know exactly what design pattern this is but it sure is pretty.

Bill Wake and I have been interviewed about Refactoring in Ruby by Russ Olsen for InformIT; you can read the interview here. (I note that my answers have been re-spelt the American way

Mês passado estava trabalhando em um sistema que estou desenvolvendo em Rails com amigos da faculdade quando um deles viu que tinha feito uma merda. Ele tinha criado um modelo “viagem” com o scaffolding mas esqueceu de colocar o plural correto no inflections. Assim o scaffolding criou vários arquivos que continham no nome as palavras “viagems” ou “Viagems” e vários arquivos que tinham em seu conteúdo essas mesmas palavras. Contudo ele já havia programado bastante coisa depois disso e ficaria ruim retornar ao commit anterior no git.
Ele já ia alterar tudo manualmente quando falei: Calma aí! Vou criar um script para isso!
Era uma boa oportunidade, já que estou aprendendo a programar em shell. Em pouco tempo criei dois scripts básicos: um para modificar os nomes dos arquivos e outro para modificar o conteúdo. Logo pensei em montar um conjunto de scripts para refactoring já que uso o combo Gedit + Terminal para programar. Daí essa semana comecei a ler o livro Shell Script Professional do Aurélio Marinho, que é muito bom livro por sinal, e dei uma profissionalizada nos scripts para colocar em prática meus aprendizados.
O resultado está no projeto Refactoring-scripts github. Por enquanto são dois:

- find-replace.sh – Busca em um arquivo, ou recursivamente em todos os arquivos de um diretório, por uma palavra e a substitui por outra.

- change-file-name.sh – Busca recursivamente em um diretório por arquivos que contenham uma palavra em seu nome e a substitui por outra.

A pretensão é, além criar outros scripts, cirar um fork para um plugin de refactoring em python para o gedit.
Mas isso é coisa para as férias de fim de ano. =)

#4 Separate Message Construction from Message Delivery

There are a variety of scenarios where you will build a message and deliver it to a destination. The message itself could be free-form text, delimited/fixed-length text, XML, or some other format. The destination itself could be a system, service, application, a server, or a human user or group of users (in the case of email). If you decouple message construction from its destination, that will drive in reuse of both of these assets. For example, you can take a message and send it via email or send to a message queue. In the same vein, you can potentially use the same code that sends email to send a newsletter message and a reminder message.

To illustrate this idea, take a look at this code fragment:

MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress(from));
message.addRecipient(Message.RecipientType.TO,
new InternetAddress("someone@xyz.com"));
message.setSubject("Hello there...");

FileReader fr = new FileReader("some-template.html");
StringBuffer sb = new StringBuffer();
BufferedReader reader = new BufferedReader(fr);
String line = reader.readLine();
while (line != null) {
     sb.append(line);
     line = reader.readLine();
}
reader.close();

message.setText(sb.toString());
// Send message
Transport tr = session.getTransport("smtp");
tr.connect("host-name", "user", "some-password");
message.saveChanges();
tr.sendMessage(message, message.getAllRecipients());
tr.close();

There is a file that is read from the file system and a data buffer is being constructed. The data is then used to send an email. However, this class isn’t very reusable because of the tight coupling between message construction and delivery logic.

Now examine, a newer version that has modularized this code – Publisher sends the message using an EmailConfiguration and TemplateBuilder constructs the message using an instance of Template.

Publisher publisher = new Publisher();
EmailConfiguration eConfig = new EmailConfiguration();
publisher.setConfiguration(eConfig);
TemplateBuilder builder = new TemplateBuilder();
Template template = builder.build();
publisher.publishMessage(template);

Now, Publisher, EmailConfiguration, Template, and TemplateBuilder are all candidate assets that are available for other classes to reuse. If you have other types of configurations, they can be included as well and bound polymorphically. This concept can be further extended based on the quantity and quality of variations. For instance, the message construction can be realized using a common interface with multiple implementations. The message itself might have standard and personalized content.

You may move to a more modular version iteratively. Which version do you think facilitates reuse, faster integration, and higher productivity? This new design will make it easier to test message construction independently from publisher.
Like this post? Subscribe to RSS feed or get blog updates via email.

Only three options are available to you once your technical debt overwhelms the development and customer support teams:

1. Continue as is.
2. Start refactoring in earnest to pay back your debt.
3. Switch to a new code base, either by launching an unencumbered development project or through acquiring new software from another company.

The first option, obviously, does not solve any problem – you simply continue a struggle that becomes more and more difficult over time. As indicated in the post Elbow Room for Handling Technical Debt, the second option is quite difficult to carry out if it is exercised at a late point in the software’s life cycle. This post examines the third option – starting afresh.

The attraction of starting afresh is always tempting. The sins of the past, hidden in layers over layers of technical debt and manifesting themselves in low customer satisfaction and poor customer retention, are (sort of) forgiven. The shiny new software holds the promise of better days to come.

Trouble is, your old sins are there to get you in three nasty ways:

1. New technical debt: Even if the shiny new software is very good indeed, it will decay over time. Unless you transformed your software engineering practices to ensure refactoring is carried out on an ongoing basis, sooner or later you will accrue new technical debt.
2. Migration: Good that the new software might be, it is not likely to provide all the functionality the old software had. Migrating your customers will require a lot of hard work, particularly if your customers developed elaborate business processes on top of your old software.
3. Critical race between old and new: For a period of time (say a couple of years) the old software is likely to run alongside the new software. Any significant new regulatory requirement will force you to update both the old software and the new software. Ditto for security. Any nifty new technology you might want to embed in your new software is likely to be equally desirable to customers who still use your old software. You will be pressed to incorporate the new technology in the old software, not just in the new software.

Before opting for new software (in preference to refactoring the old software), I would recommend you compare the economics of the two option. My rule of a thumb for the calculus of introducing new enterprise software to replace legacy software is straightforward:

For a period of about two years, assume the run rate for dev/test/support will be 150% of your current investment in development, test and support of the old software.

Please note that the 150% figure is just the expected run rate for running the new software alongside the legacy software. You will need, of course, to add the cost of acquiring/producing the new software to the economic calculus.

You might be able to reduce the ‘150% for two years’ investment by applying some draconian migration measures. Such measures, of course, will affect your customers. In the final analysis, your decision to acquire new software must be viewed as the following simple question:

What value do you place on your customer base?!

It happens a lot, especially when working on legacy code, that you can’t figure out a “business logic” algorithm that isn’t already well documented. Sure, it’s in the code, but so are a million other things, and you can’t eyeball the part that does all the calculation. The client is asking for a change or a fix and you’re not sure where to start.
That’s when I think you can do three things at once: improve the overall structure, impose some unit testing, and solve the problem you were asked to. Refactoring does all of these.

Long story short

Refactoring is the practice of changing existing code to improve its structure without changing its function or effect. Ordinarily you do it when something changes in the requirements. For example, the simple structure that works fine when your software supports only one state’s regulations has to turn into a lookup table when you add another state.

Sometimes the requirements change is implicit though. The old system worked because Rick patched it to death, and Rick isn’t here anymore, and the new requirement is someone besides Rick has to know what it does. Commenting is a well-known (because it’s easy) but also widely ignored (because it’s rarely accurate) way to communicate, but you’re probably better off letting the code do the talking.

What that means

Suppose you’re doing a WinForms application and an event handler does an important calculation. You want to figure out what that calculation does, because it probably needs to be changed, but it’s entangled with all the code that updates the GUI and saves some stuff to a database.

The thing to do is create at least a token class that pulls the calculation into a single method or group of methods. To wit, you’d edit this:

Private Sub btnGo_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles btnGo.Click
btnClose.Enabled = True
btnUpdate.Enabled = False
Dim moneyvalue as Decimal
moneyvalue = ... ' Complex money calculation here
txtPrice.Text = "$" & String.Format("Order Total: {0:C}", moneyvalue);
End Sub

Into this:

Private Sub btnGo_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles btnGo.Click
btnClose.Enabled = True
btnUpdate.Enabled = False
Dim quantity as Integer
Dim moneyvalue as Decimal
quantity = Integer.Parse(txtQuantity)
moneyvalue = calc.GetTotalPrice(quantity)
txtPrice.Text = "$" & String.Format("Order Total: {0:C}", moneyvalue);
End Sub
Public Class PriceCalculator
   Public Function GetMoneyValue(qty as Integer)
      ' Complex calculation goes here
   End Function
End Class

The simplest thing that could possibly work

What’s the point? You haven’t changed any functionality at all!

Yes, that’s the point. You have the exact same inputs and outputs, but now the PriceCalculator class can be maintained free of GUI pollution. The next step is to download something like NUnit, add it to your project, and create unit tests for all the methods of the PriceCalculator.

Here’s the crazy thing. When you write unit tests for the existing code, you will gradually close in on the intended (and actual) functionality of the code you’ve refactored. So while you put the code into a more testable format, you are also getting closer to understanding enough to make the change, and making it much easier to modify in the future.

Look, I know you’re busy. You want to do, as they say in Extreme Programming, “The Simplest Thing That Could Possibly Work.” I’m saying this is the simplest thing that could possibly work!

Two reasons for that

For one thing, the dependent clause is important. The “simplest thing” is no good if it doesn’t work! And by “work” we mean a solution that doesn’t create more headaches than it removes. Hacking at pre-existing financial code in a GUI event handler? Well, that doesn’t work, almost tautologically. Because in the end you still have financial code in a GUI event handler.

The other thing is that the default approach, that of modifying the code in place and hoping you got it right, isn’t the simplest thing. It’s a lot of work! And it’s error-prone, which means you have to do it again probably, and that isn’t simple either.

The cost of refactoring

If you choose your oppportunities carefully, refactoring makes your code better at no cost because it is only the shortest path to getting the right answer that you wanted anyway. Truly, the question isn’t whether you have time for refactoring; the question is whether you have time not to.

A chance to talk

Do you work in a shop where obvious refactorings are “a waste of time”? Do they turn your best estimates to mush? Is it hard to do your best work because they won’t let you fnish things? I can’t immediately solve those problems unless you hire me, but I can provide a place to talk and vent.

Take five minutes away from whatever is frustrating you at the moment, and bend it to my survey on the Developer Bull Session concept. Let me know if you’re interested in talking or listening in a voice (!) conversation now and then, via conference call or stream.

Como havíamos publicado no início de outubro, a Bluesoft patrocinou o evento Encontro Ágil 2009 que aconteceu na Universidade de São Paulo nos dias 10 e 11 de outubro de 2009.

No primeiro dia rolaram diversas sessões em paralelo, todas apresentadas por grandes nomes do meio de desenvolvimento ágil nacional. Já no segundo dia houve uma série de apresentações com Joe Yoder (americado) e Jutta Eckstein (alemã) no auditório da FAU.

A integração com a galera foi ótima durante estes dois dias através dos “Birds of a Feather”, discussões sobre um tema proposto por algum participante com a finalidade de distribuir o conhecimento. Outro pronto chave para esta integração  foi  o almoço que aconteceu no próprio local.

Veja os slides desta palestra realizada por André Faria, Luiz Faias Jr e Robson Santiago com as licões aprendidas no evento:

Assista também o vídeo que encontra-se disponível em nosso canal do Vimeo:

In an earlier post, I outlined the four key ingredients for agile software reuse. One of which is the reuse roadmap. In this post I want to share an example roadmap and illustrate how they tie into other business and IT objectives. The idea is to start at the ad-hoc state (where there is little or no reuse) and move to truly utilizing systematic reuse across multiple projects.

Phase 1-Ad-hoc - In this initial phase there is little or no awareness of reusable assets, and there is very little customer integration expertise. Consumers have low awareness of what assets are available. Systematic reuse efforts not considered and there is a lack of alignment between project deliverables, reuse strategy, and business objectives. Applications within the same domain do not share assets i.e. there is a lot of duplicate code.

View Reuse Roadmap

Phase 2-Aware - In the second phase, legacy capabilities and processes are mined for building assets. Agile practices are minimally aligned to the reuse strategy. Consumers seek reusable assets for applications in the domain and rudimentary product lines take shape. Communication about reusable assets have improved and awareness is increasing.

Phase 3-Ready – In this phase, asset inventory expands task, entity, and utility capabilities. User stories are analyzed within a product line context and additional assets are built iteratively. Agile practices specifically code reviews, refactoring, iteration planning, and pair programming used to identify and refine assets in a continuous fashion. Consumers increasingly use reusable assets to build applications and start to co-create assets. Additionally, assets are used across multiple applications in the domain. A few business process flows start to leverage reusable assets.

Phase 4-Systematic – This is when your systematic reuse program starts to really reap rewards. Asset inventory expands to include additional capabilities in your domain. Assets are used to automate many more business processes and they provide variability mechanisms to meet business needs. User stories and iteration planning are well aligned with reuse strategy which facilitate iterative reusable asset development. Additionally, several assets built by refactoring legacy capabilities and communication about reusable assets are available. Finally, consumers are actively engaged in asset co-creation, retrieval, and consumption and supported by a mature integration function.

Like this post? Subscribe to RSS feed or get blog updates via email.

Here are a few points to consider while you refactor existing or new software assets for reuse:

• If your team is building reusable assets for multiple applications (as part of a product line) within your control you could use a library approach (a JAR or DLL). How you package and deploy the asset is dependent on the development platform. Similarly, if your team is building reusable assets for external applications outside your control, it is better to with a service oriented approach.
• Deploying reusable assets can be tricky! Spend some time thinking about how this asset will work within your environment. Is it going go be centrally deployed for all consumers? Or will each consumer have a copy of the asset in their application? If there are multiple copies, how will you track usage metrics?
• Make sure you have covered security requirements. Your shop might have special information/privacy standards and even legal ones to comply with. Ask around.
• Large shops might have enterprise standards that you might be forced to comply with. Work with the appropriate folks to avoid roadblocks when you deploy!
• A good rule of thumb is to seek input from your production support team (or your own team if you play that role) for understanding their needs. Think of production support input as part of your refactoring effort. Sure you can get away not doing this but why waste a precious opportunity to build a higher quality product while strengthening the partnership.

Don’t wait till the end of your iteration to consider these issues. You will have higher success with systematic reuse if you work these details out as well.

Like this post? Subscribe to RSS feed or get blog updates via email.

I wrote earlier about using agile software reuse and the key ingredients that are beneficial when pursuing such a strategy. In this post, I want to summarize how agile practices can be used to build reusable service capabilities.

This isn’t an exhaustive list of agile practices that facilitate reuse – consider these as a starting point.

Like this post? Subscribe to RSS feed or get blog updates via email.

In the hectic routines of projects and deadlines it is easy to ignore reuse. After all, we are delivering code, features, and churning out applications – aren’t we? May be you are waiting for the right time to start and execute on a reuse strategy. May be you think software reuse is a big myth and isn’t worth pursuing. Regardless of reason poor design will eventually inhibit your efforts to more agile and responsive to business needs. Here are ten tell-tale signs that your team needs systematic reuse:

1. Management believes they can install or buy reuse. You are told reuse comes for “free” with OOPS, SOA, BPM, MDM, (you can add your favorite buzzwords here!). Nothing could be farther from the truth
2. There is no management support for reuse. You typically hear some variation of deliver, execute, and just hit the deadline. What should be a small change rapidly mushrooms into something that touches several classes or services and forces you to change code across modules. To boot, this happens often. This of course adds technical debt and will hurt the team in the long term.
3. Developers love to build their custom implementations for which satisfactory solutions exist. It could exist in-house, in the open source community, or available commercially. We have all met the developer who wants to build a better logger than Log4J or a better dependency injection container than Spring. Whatever. The argument usually goes this way: we have special requirements that no one else has and we have the best talent to build it (maintenance, ongoing bugfixes, support costs are conveniently excluded).
4. No scope for reuse in the problem domain.  Nothing can be considered for reuse you are told. Our domain is so unique that it changes often – nothing is common across projects or initiatives and we need to keep churning out code to meet business needs. This might be true to an extent but not the way it is portrayed.
5. Your developers and technical leads tell you that their software assets are perfect – they have been made completely reusable for all future needs. Be very wary! Predicting the future is tricky and systematic reuse isn’t going to guarantee perfection. More importantly, your investment in reuse is going to provide you the foundation to turn out new features and business processes quicker but doesn’t eliminate the need for continuous evolution of those reusable capabilities.
6. There are several different versions of a common need like getting customer data or getting a database connection. Each with its own set of assumptions about data structure, error handling, etc. You know there is an opportunity to create a common capability but developers find it easy to cut and paste code from one project or component into another.
7. Each developer implements capabilities without the faintest idea of existing ones. You find duplication sprinkled liberally across your codebase – all trying to do the same thing in multiple ways. Each developer of course believes that they were the first ones to implement it (and implement it right!!).
8. Design is an after-thought you are told. Why waste time in design when you can implement? No, you don’t want big design up front – and you also don’t want the opposite. This sign usually manifests itself during testing – you discover the same need across sub-systems or modules. A little design would have discovered this as a reusable capability early on.
9. There is no investment in training, documentation, communication, or integration support for reusable assets. If you build it they won’t come and you end up with a library of assets that are buggy, unusable, and worse – irrelevant to business needs.
10. You have no hooks in the development process that will help you proactively take advantage of reuse opportunities. Reuse if any happens ad-hoc due to heroic efforts of one or two developers sporadically.

Have any of these signs resonate with your experiences? are there additional ones you can suggest?

Like this post? Subscribe to RSS feed or get blog updates via email.

From time to time I find myself needing to replace certain strings globally (eg: in a directory tree), or deleting lines based on a match. I find sed extremely annoying and I don’t manage to get around its syntax. So ruby comes in handy!

replacer.rb

exp_search = '<%=launchBean\.getCustomVersion\(\)%>'
exp_replace = '${xsession.info.launchBean.customVersion}'
directory = '**/'
file_mask = '*.jsp'

Dir.glob(directory+file_mask).each do |file|
  File.open(file, 'r+') do |f|
    content = f.read
    if /#{exp_search}/ =~ content
      s = content.gsub(/#{exp_search}/, exp_replace)
      f.rewind
      f.write s
      puts "#{file}: #{content.split(/#{exp_search}/).size-1} matches"
    end
  end
end

deleter.rb

exp_search = 'useBean.*launchBean'
directory = '**/'
file_mask = '*.jsp'

Dir.glob(directory+file_mask).each do |file|
  count = 0
  content = ""
  File.open(file, 'r+') do |f|
    while line = f.gets
      if /#{exp_search}/ =~ line
        count += 1
      else
        content = content << line
      end
    end
  end
  if count > 0
    File.open(file, 'w') do |f|
      f.write content
      puts "#{file}: #{count} lines deleted"
    end
  end
end

These commands are especially useful if you have to refactor a codebase that doesn’t provide direct support with refactoring tools. In this case, I was refactoring a few hundred JSPs of a legacy system.

Credits to RSF & Ruby One-Liners for most of the code & ideas. rcscript seems to be a bit too much for me at this time, I’m perfectly happy modifying replacer.rb and deleter.rb when I need it.

I learned the KISS acronym (Keep It Simple Silly) a long time ago. Looking back on my
career, I see the wisdom that the KISS acronym teaches.

When I was enhancing software or using some software (or website) and a recurring thought would cross my mind.  This thought was”what were they thinking about when they designed this screen (or web page, software, …)?”  It is a good bet that some of you might have had a similar thought. 

What prompts that thought though?

Most often, it is simply about cramming too much information into the screen (or web page or software , from now on I will simply refer to both a screen and web page and software as software).

This data overload comes in the form of text, images, and data entry controls. There are resolutions using KISS to redesign the software. I propose 4 strategies to how to re-design (or refactor)  the software screen to alleviate the information overload. In the next 3 blog entries, I present those 4 strategies.

Stay tuned for more

This week I decided to give you, my dear readers, a little rest from my blabbering and go technical a bit. I am going to talk about a very powerful and a personal favorite NetBeans feature: Refactoring.

If you do not know NetBeans, it is a free, cross-platform, open-source Integrated Development Environment (IDE) for software developers and a product of Sun Microsystems. An IDE is a software application that provides extensive facilities to programmers for software development, such as a source code editor, a compiler, an interpreter, build automation tools, and a debugger. For more information about NetBeans’ features, visit the official website.

Refactoring is about changing your source code easily. Imagine moving a class between packages and having to edit the package statements manually at the top of each file, or wanting delete a variable in the code and not knowing if it is referenced somewhere else in your application. Performing these types of operations manually can be time consuming and prone to error. However, with the advanced refactoring capability available in NetBeans, you can do such changes very easily. NetBeans provides many refactoring options on its Refactor menu. I am going illustrate half of them today and the other half in a following post.

For this post I have created two classes, ImportingClass and MoveClass. View them here and here.

There are some images that are not very clear because of page size limitations. You can click on any image to see it in full size.

Rename:

Rename refactoring allows you to change not only the name of the class but also any constructors, internal usages, and references to the renamed class by other classes. You can also rename the package, which will automatically rename all instances of the package name in your code, including comments. Here, I am going to change the name of the variable value to AddedValue in class ImportingClass:

Automatically, the variable name is also changed in class MoveClass:

Move:

Moving a class from one package to another may seem like an easy task; you just have to copy and paste the contents of the source file into the new directory and then edit the package statement at the top of the file then you are good to go. However, if other classes import or reference that class, then the developer must also search through and modify those files. Here is how you can move MoveClass from the refactoringpackage2 package to refactoringpackage1:

Copy:

Copy refactoring allows you to copy the contents of a class to another package, automatically changing the package statement at the top of the source file.

Safe Delete:

Sometimes when you are reviewing a previously written code, you decide to remove a class member variable that you think is not used, only to find out that it does indeed appear in your code, and then your class does not compile. With Safe Delete refactoring, you can identify each usage of a class, method, or field in code before deleting it. I am going to illustrate it by trying to delete the AddedValue variable from class ImportingClass:

However, the variable was referenced in class MoveClass, so deleting it would cause an error. T=NetBeans alerts you to that, and can even show you where the member you want to delete is referenced if you clicked the “Show Usages…” button:

Change Method Parameters:

Change Method Parameters allows you to safely change everything in a method header- access modifier and arguments- and notifies you if this change is going to affect your source file. Here, I am going to try to delete the parameter x of the display method of class ImportingClass:

Parameter x is used within the method body, and so a warning is displayed:

For the following examples, I created a class called Truck, which inherits fr0m a class called Vehicle. View here.

Pull Up:

When working with classes and superclasses, Pull Up refactoring is very useful. It allows you to move class members and methods from a subclass up into the superclass.

Push Down:

Push Down is the opposite of Pull Up refactoring. It pushes a superclass member down into a subclass.

And that’s it for this time, note that those are only half of the capabilities of NetBeans refactoring. I am going to go through the other half in a following post soon. If you have any question or comment, do not hesitate to contact me.

There are many software development methodologies out there – some are beaurocratic, with a big design up front, some are agile, with lots of practices to follow, and some are “lean”, where you’re given guidelines on how to optimise the flow of new requirements into features. Or whatever.

Today, i’ll be looking at how to create your very own agile process, based on lean principles – imagine that! Your very own process! You then have to write your own book on it and defend it to the hills (this is left as an exercise to the reader).

Choose your process

You need to pick 1 (yep, just 1) practice from under each of the bullet points.  If a practice is repeated you should pick a different one, unless you want to be ultra-lean.

1. Eliminate Waste
   • Test driven development
   • Simple design
   • Measure velocity
   • Reduce task switching
   • Make value flow
   • JIT development
2. Create Knowledge
   • Pair programming
   • Perform retrospectives
   • Do spike solutions to difficult problems
   • Collective ownership
3. Build Quality In
   • Pair programming
   • Test driven development
   • Peer review
   • Coding standards
4. Defer Commitment
   • Incremental design
   • Short iterations
   • Refactor
5. Optimize the Whole
   • Continuous integration
   • Refactor
   • Automate everything! (Tests, build process, release process…)
6. Deliver Fast
   • Continuous integration
   • Optimize workflow (eg. limit 3 items in the “ToDo” stage)
   • Short iterations
   • No BDUF
   • JIT development
7. Respect People
   • Daily Scrum
   • Collective ownership
   • Sustainable pace

You should now have 7 practices. If you have fewer (eg. you’ve chosen pair programming for “create knowledge” and “build quality in”), then you’ll need to defend your process more by saying your developers are smart.

If you think your developers aren’t that smart, or you don’t trust that your set of practices will reinforce each other, go and select a couple more practices to be on the safe side.

Now argue

The most important thing is, of course, how well you argue that your new process is better than all the others. I’ll give you the process i have selected, and show you how to argue about it:

1. Test driven development
2. Pair programming
3. Peer review
4. Short iterations
5. Continuous integration
6. JIT development
7. Collective ownership

An argument may now ensue:

You: Your process doesn’t involve the customer enough – how do you make sure the correct software is written?

Me: Obviously “collective ownership” extends to the customer – they need to take equal responsibility for the development. We also have short iterations which means, of course, we have regular release to the customer, so they can be sure we are moving in the right direction. And because of our other practices, the code that’s released will always be production quality!

You: Well, that won’t work for us because…

Me: Either (a) You’re not doing it right! or (b) Obviously you need to change it slightly for your circumstances…

So the next time you find your current process isn’t working for you, revisit this blog post and create your own! You can swap-in and swap out whatever practices you want under 1 heading, or just do them all and say you’re doing XP!

Whilst this is tongue in cheek, the question you should really be asking yourself  is: does the process you are currently following cover the above 7 process headings. If not, is that something you can live without, or are you missing something? And you really should be doing at least those 7 things…

I don’t personally use Resharper, but a few developers i work with love it, so i thought i’d give it a go.

I won’t bother reviewing it, as that’s something that’s been done everywhere already, but i’d like to highlight 1 particular danger of using such tools: these tools may suggest you do things which are dangerous, and are bad programming practice.

I am posting specifically about Resharper’s hint to replace all variable declarations with the var keyword.

So i looked on the internet, and saw that other people have similar concerns about using the var keyword. I don’t share all those concerns – i think it’s worth using when a variable is created on the same line it is declared. I think it’s very dangerous to use it when capturing the return value from a method call.

This is okay:
var myList = new List<int>();

This is not okay:
var myList = peopleDataAccess.GetPeopleIDs();

If you are not familiar with C#, or especially if you are not familiar with the new features being added to C#, it’s tempting to take Resharper’s suggestions on face value.

However, in the second example above, myList is now depending on the return value of a particular method. If that method is refactored such that the return type changes, the line above will still work fine, but using the variable elsewhere in the function will probably cause a compile time error. If you were explicit and said what you expect the method to return, the compiler would point to the declaration of the variable being wrong, not the use of it.

This is a big problem if you have many developers working on a project – if you change the return type, and update all the references, other developers may still get problems when they update to the latest version on their branch and get strange “method doesn’t exist” errors at compile time. If they were to instead get an error on the variable declaration line, they can see GetPeopleIDs now returns a PeopleIDCollection object (for example), rather than a list of integers, and fix the code much more quickly.

Why make developers hunt around for the cause of the problem, when the compiler can point to the cause directly?

So the moral, if there is one, is probably: Be wary of the advice that tools are giving to developers.

What do you do when your project already sucks, and it’s already late, and the design you’ve been committed to is Hell?

I have this thing I do; I sort of call it “Emergency Agile.” Note that it’s completely wrong by normal standards but it kind of gets projects off the proverbial dime.

You totally want to read more about this, and you will, if you get onto my eZine mailing list. You get a complete mailing about once a month, with articles and links and special offers that help you do your job, as well a quick note every week or so with something funny or interesting. Do you need more stress? No? Then this is for you.

Anyway, here’s how I deal with Design Hell.

First thing

You know what? Projects get messed up for good reason. Software design and implementation is really difficult, defintely more difficult than your management grasps. I keep getting called ostensibly because this or that team member is a jerk or over his head or not working hard enough. This very rarely turns out to be true. The world of software development is full of clever, hard-working, professional people.

Nobody does a bad design on purpose. Got it?

Second thing

Almost always, there is some particularly big obstacle, but it can be at any conceptual level. Finding that level is the key. Is it as simple and direct as a specific, deep bug? That’s awesome, because you can find it and fix it and be on your way.

As a software practitioner, one of the coolest and most useful skills you can develop is that of reading other people’s code. It’s cool because it’s difficult, combining technical kung-fu with a rough-and-ready psychology. It’s useful because it prevents having to rewrite the entire system from scratch. In particular, it’s good to make a separate model of the code, something you can put in prose or on a whiteboard. Keep refining that model as you discover more and more about the existing code. Quite soon some patterns will emerge and repeat themselves.

Sometimes underlying it all is an overall design issue–like a messy class hierarchy that’s hard for normal people to follow, or a key data structure that nobody’s quite explained. One time I saw a four-dimensional array in JavaScript that drove everything in the application but had no descriptive comments at all!

Or you might find that the toolset is completely disconnected from the purpose of the application, such as n-tier applications done (in this decade) with Visual Basic 6 in the middle. (Sure you can make it work, but what a slog.) The original developers may have had great knowledge and the best intentions, but they were stuck working without implementation inheritance and a fairly weak standard class library.

In any case,the point is to answer the very general question: “What is it that we’re looking at?” Is it a solid design with a lot of implementation bugs? Is it overly ambitious? Did the first developer fail to understand inheritance, or when to use composition or interfaces instead? Is it way too highly coupled? (I see that one a lot.)

Big Ball of Mud

Very likely, though, your design issue is that there is no design. This is often referred to as the Big Ball of Mud pattern: “a casually, even haphazardly, structured system.” What a pain! These systems are particularly hard to understand and modify. The good news is that the Ball of Mud gives you free rein to reformat and refactor the code; since there is no design, you can’t possibly break the design.

Next thing

Whether you’ve got a Big Ball of Mud, or just badly suited design, the key is to use what you know about what’s wrong to create quick and incremental design improvements. There’s more than one way to accomplish that, and the right way depends so much on the details of your project, but here are a few wicked short-term techniques for getting the code under control:

• Pair-program the easy parts first.
• Collect selected globals into a Singleton class, then control access to them.
• Run over the code with ReSharper or similar.
• Pair-program the hard parts first.
• If the design was too ambitious, extract the simplest parts and keep them.
• Intentionally break highly coupled code. Stitch it back together with loose coupling.
• Document the data structures, even if you have to guess a little.
• Profile the code to find out what sections are never called, and remove them.
• Impose naming conventions, which sometimes help reveal patterns in the code.

When you do this, the design of the existing code isn’t so much created as discovered and shaped as you go along–less like architecture, more like sculpting.

Back to the first thing

If you make design improvements quickly as you go, you’ll doubtless find things the previous developers did right. Take a moment to appreciate their skull sweat, even as you regret the things they did wrong. Software development is an inherently difficult and frustrating task. There’s nothing wrong with sharing a laugh over some really bad code, but remember the goal is to build maximum value with what you have.

Good luck getting out of Design Hell! Do it one little bit at a time, but quickly.