Entries Tagged 'programming' ↓

In a comment a while ago, David wanted to know why are Singletons the root of all evil. Well, that’s just because they are!

Ok, it is not that easy. Nor that black-and-white, either. Let’s see if I can articulate some of the reasons why Singletons are bad for you and for your code.

From all the varieties of pattern abuse out there, singletonitis is the most irritating one because of two simple reasons:

1. Singleton is one of the patterns with the worst side effects.
2. Singleton abuse is one of the most widespread varieties of pattern abuse.

In 99% of Singleton occurrences, the Singleton pattern was unnecessarily introduced with one of the following excuses:

• Some object needs to access a resource that isn’t available in that abstraction layer. The right solution to this problem is to redesign. Solving bad design by throwing a pattern at it just makes things worse.
• As a glorified global variable. Global variables can be avoided most of the time, and they should be avoided wherever possible. See previous point on solving bad design by layering patterns on top.
• Premature optimization (”we shouldn’t instantiate this more than once, or it will bring down performance; let’s singletonize it!”). Thousands of wise words have been written on the evils of premature optimization, so I won’t go into that here.

So it all boils down to the following: in most cases, programmers introduce Singletons either as a misguided attempt to improve a bad design, or as a means for premature optimization.

Singletons not only have the noxious effect of obscuring how objects collaborate, but they also hamper dependency injection, which in turn makes testing and refactoring extremely difficult. Thus, Singletons lead you into a spiral of unmaintainability. To think that they were unnecessary in the first place!

Apple Insider has published a detailed, enlightening and simply beautiful history of the Mac OS System Preferences panel, Road to Mac OS X Leopard: System Preferences.

The brief mention and screengrab of the NeXTSTEP Display Preferences panel almost made me reach for a Linux workstation to run WindowMaker on. Almost.

(via SwissMiss)

[Originally posted on what used to be a separate blog 'On jobs, work and careers' and later was merged into this blog.]

Interesting links on the topic of jobs, work and careers:

• Enrique Dans: ¿Alguien ha visto un programador? (Has somebody seen a programmer?):
  

  En España, a este lado del túnel, se necesitan programadores. Y los programadores necesitan una reivindicación urgente de su profesión, que recupere el legítimo orgullo de quien crea, de quien desarrolla, de quien se responsabiliza de un todo, de quien se enamora de un proyecto y no se limita a ser un obrero en el mismo, sino un verdadero arquitecto. Se buscan programadores con orgullo y capacidad para serlo. Pero por lo que se ve, habrá que mirar debajo de las piedras.

  Rough translation:

  In Spain, on this side of the tunnel, we need programmers. And programmers urgently need to claim back their profession, they need to recover the legitimate pride of someone who creates, develops and is responsible for a whole, of someone who falls in love with a project and doesn’t limit himself to being a mere labourer on it, but is a real architect. We need proud programmers and programmers with the skills to be one. It seems they will be hard to find.

• The Business of Software Wiki (from Joel on Software):
  

  Our goal is to gather and present unbiased, useful and up-to-date information about the business of software, whether it’s microISVs selling desktop software, Web 2.0 sites, or even the big enterprise kind of outfits.

• Brazen Careerist: How to be a star performer: 4 things to get good at (yes, this one’s a year old, but it’s still a good read):
  

  To become your best self – a star, a great leader, a fulfilled worker – you need to know yourself and your goals very well. Start now. It’s a lifelong process, and done honestly, it’s the process that makes almost any job intrinsically challenging and interesting.

Nice reflection on Skrentablog on reducing clutter in your codebase. Code is our enemy:

Code is produced by engineers. To make more code requires more engineers. Engineers have n^2 communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs.

You should do whatever possible to increase the productivity of individual programmers in terms of the expressive power of the code they write. Less code to do the same thing (and possibly better). Less programmers to hire. Less organizational communication costs.

This doesn’t apply just to code. It applies to almost everything: less clutter leads to less overhead (of various kinds) leads to improved results. See, for example, Merlin Mann’s recent post on his personal war on clutter.

I read in Ars Technica that Most IT projects in Europe are late. According to the article,

The main reasons for delays, according to the survey, were outsourcing, changed project goals, and poor managerial coordination

The numbers listed in the original BBC article, suggest that the European country more likely to deliver on time is Sweden, where 44% percent of IT projects make or time. Spain and Russia are at the bottom of the list, with only 4% (!!) of IT projects delivered on time.

This is June 2007, more than 6 years after the Agile Manifesto was published. And we still can’t manage the volatile nature of IT requirements. Apparently we can’t really manage much in IT, anyway.

I wonder why is that? Is it really all that difficult to manage customer expectations and work in nearly-continuous-re-planning mode, adapting to changing priorities and requirements?

There are successful IT companies that hardly ever need to push a deadline, so it is definitely possible to do a good job of an IT project and to do it on time, too. So is really the majority of the IT industry so incompetent?