Naming Things

Naming Matters

For programmers, naming is an important activity:

  • It has a significant impact on code readability
  • We do it a lot

General Principles

  • Don’t make me think
  • Make wrong things look wrong
  • Take time to go fast

General Guidelines

  • Don’t be a perfectionist – don’t let naming paralize you
  • If you can improve it, do so
  • Remove the comment and improve the name
  • The wider the scope the longer the name

Follow Standards

  • Follow platform conventions
  • Call things the same as they are usually called
  • Use programmer speak for programmer things (solution domain)
  • Use the customer’s language to describe the customer’s things (problem domain)
  • Spell consistently and correctly
  • Pick one word to describe a concept and stick to it
  • Don’t inventing language where you don’t need to

Encourage Communication

  • Use pronouncable names
  • Invent language where you need to
  • Don’t be cute, clever or funny: not everyone will get it
  • Avoid cultural references

Be Useful

  • Avoid disinformation
  • Avoid noise words – words that don’t add anything (a, the etc.)
  • Avoid redundancy
  • Use searchable names
  • Think sortability – this will depend on the IDE
  • Avoid hungarian – it doesn’t usually add anything
  • Add context where it helps, remove it where it doesn’t

Specific Scenarios

  • Class names: noun-phrases, not a verbs
  • Method names: verb-phrases, not nouns

Further Reading

Data Crisis Management

A few notes on how we are managing a data crisis:

Communication

  • Who do we need to tell?
  • What do we need to tell them?
  • When do we need to tell them?

Impact Analysis

  • Who is affected?
  • To what extend?
  • What are the consequences?

Resolution

  • Do we fix everything in a systematic way or deal with the problem on an ad-hoc basis when people tell us it is a problem for them?
  • What should we prioritise?

 
 

BizTalk: Problem starting file receive location

The Problem

I was having trouble getting a receive location started. Every time I attempted to start the receive location an error message was added to the event log and the receive location remained stopped. The error message was something like this:
The receive location "<PortName>" with URL "<FileLocation>" is shutting down. Details:"The Messaging Engine failed while notifying an adapter of its configuration. ".
The transport type of this receive location is FILE.

The Solution

I’ve encountered this several times before. The solution was to make sure that the <FileLocation> exists and that the security principle under which the receive location is running actually has permission to access the receive location. Once I did this, the receive location started first time.

Can't Open BizTalk Project in VS2008

If your VS2008 BizTalk developer machine looses its ability to open or create BizTalk Projects, the reason is probably that a registry key has been overwritten by an update or repair to Visual Studio. The resiltuion is to find the registry key and reset it to its correct value.
The registry key can be reset as follows:
For 32-bit versions of Visual Studio 2008, the registry key is:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftVisualStudio9.0Projects{FAE04EC0-301F-11d3-BF4B-00C04F79EFBC}PossibleProjectExtensions

For 64-bit versions of Visual Studio 2008:

KEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftVisualStudio9.0Projects{FAE04EC0-301F-11d3-BF4B-00C04F79EFBC}PossibleProjectExtensions

Change the value from

csproj

to

csproj;btproj

VBScript to Get Domain Groups for Current User

This take me back a bit…

When Improving Technology Makes Things Worse

A Secret

We all know that bad technology is bad for business. By “bad” I mean technology that doesn’t do what it is supposed to do, or which does it wrong, or which costs more to implement than the benefits it brings.
But I’ll let you in to a secret:

Good technology is sometimes bad for business.

Now, I develop software for a living, so I shouldn’t really be telling you that. I should be saying that good technology is a good thing – especially software – and that it will increase your bottom line, make you more productive, make you happier and generally improve your life.
And each of these things is true… but only some of the time.

The Problem

The problem is this:

  • Good technology makes processes more efficient.

At first sight, this sounds like a good thing. To understand why it often isn’t so good, consider two effects that technology will have on an organisation:

Efficiency and Effectiveness

According to Jim Collins (in Good to Great), “great” organizations all employ technologies that enhance their competitiveness. Collins also confirms the role that technology can play if you don’t keep up. However, he explains that technologies are accelerators that amplify the company’s strengths and weaknesses. This means that a company that aims to improve processes by adding technology will magnify both the good and the bad aspects of those processes. In any business area where practices are less than perfect, the imperfections will be amplified by technology. The problem is that making processes more efficient doesn’t necessarily make them more effective.

Lock-In

The other effect of introducing technology is that it can be a hindrance to change. A new software system, for example, can be a very costly acquisition (especially given that companies often underestimate the cost of software). Once the software is deployed, however, processes become locked-in to the way the software operates. Changes to processes often require changes to the software – which can be prohibitively expensive. The result is that the company looses agility, becoming bound to outdated practices that they know are broken, that they want to change, but which are impossible to shed because of technical constraints.

An example of this is the clocking system that was used at a company where I did some work. It was based on decimal hours rather than hours and minutes, so 7 hours and 30 minutes appeared on screen as 7.5. Everyone knew that this was a bad idea, because the entire staff of the company wasted time every month converting their clockings from hours and minutes into decimal hours. However, this method of working was locked in by the technology. When a companion time-sheet system was introduced, the specification indicated that it should also work in decimal hours so it would be compatible with the first system, further locking-in wasteful behaviour.

Conclusions

So, does all this make all technology a bad thing? Not at all. But it does suggest that we approach technology in a different way:

  • Great companies value technology.
  • Technology should not bee seen as a panacea, but a method of amplifying existing practices.
    • Business needs should drive technology, not the other way around.
    • Business systems should be fixed before introducing technology to make them more efficient.
  • Technology should be chosen on the basis of how easy it is to change as well as on how well it meets current needs. For example:
    • Choose an Agile approach to bespoke software development.
    • Reduce dependencies between technologies.

SQL Server: Example Naming Convention

An example of a SQL Server naming convention I have encountered:

Tables

  • tcTableName (e.g. tcAsset) for core tables, i.e. tables that contain regularly changing data and have insert/update/delete queries run against them.
  • trTableName (e.g. trAssetType) for reference tables, i.e. tables that contain static/unchanging data, usually used in reference to data in core tables.
  • tjTableName (e.g. tjUserRole) for join tables, i.e. tables that provide a many-to-many join between two other tables.

Columns

  • tableNameId (e.g. assetId) for primary keys.
  • foreignTableNameId (e.g. assetTypeId) for foreign keys.
  • name” for text fields in simple ID/Name tables, e.g. in trAssetType (assetTypeID int, name nvrachar(100)).
  • lowerUpperUpper (e.g. propertyEntranceStorey) for all other columns, with no particular convention on the column names other than the lowerUpperUpper case.

Views

  • vwTableNameSubset (e.g. vwAsset, vwWindowHistory, vwWindowHistoryLatest)

Other

  • Stored Procedures: uspTableAction (e.g. uspAssetDelete) (usp = User Stored Procedure – don’t use “sp” as its reserved for system stored procedures and SQL Server always checks the Master database for the SP first before checking the current database, meaning its bad for performance).
  • Functions: fnXXX
  • User-defined Data Types: uddtXXX
  • ID Columns: tableID / foreignTableID (e.g. assetID / assetTypeID)

What Makes Technology Popular?

It is easy to assume that technology becomes popular simply because it is better than the competition. But as the saying goes, “that ain’t necessarily so”. In fact, the history of innovation is replete with examples of inferior

technologies capturing a larger market share than their technically superior rivals.

Some of the best known (and hotly debated) examples of include:

  1. Betamax / VHS
  2. Ethernet / Token Ring
  3. Mac / Windows
  4. Firefox / Internet Explorer

Moreover, there are also plenty of perfectly good technologies that die a death because they lag far behind their rivals in terms of sales, despite their being little difference in their technical merit. Most format wars are a case in point.

So, why does this happen? How does a technology come to dominate the market, often at the expense of other, sometimes superior, alternatives?

The answer lies in the way that individuals make decisions about the technology they use. The technology that gets picked for three reasons:

  1. It meets a need (or at least appears to)
  2. It gets publicity – sometimes through deliberate advocacy, sometimes through word of mouth
  3. There costs of adoption are outweighed by the benefits

To illustrate, we’ll consider a well-known example: the Windows operating system.

Firstly, users who get what they need from Windows are unlikely to go looking for alternatives. They might do so, however, if they start to believe that their are problems with Windows that reduce their productivity. For the majority of Windows users, however, Windows meets their needs. Whether that is because it is a great product or because the users don’t know any different is irrelevant. The point is that for many users, it is simply good enough.

Secondly, even if they go looking, Windows users are unlikely to find out about many of the alternatives. This is because they just don’t receive very much attention from developers, other users nor the press. How many Windows users have heard of the Haiku Operating System, for example? On the other hand, it is more likely that they will have heard of the Mac or Linux.

Finally, even if Windows users find an alternative, they won’t switch unless the benefits of switching outweigh the costs of adopting the new platform. If critical applications are available on the new platform, users might switch. If not, they are unlikely to do so. Similarly, if the learning curve is steep, they may be reluctant, but if the user experience is similar, they may be more willing to do so. Ubuntu is a popular Linux distribution because of the focus on usability, whereas others are less so because they’re difficult to get used to.

So, there you have it: technology is not popular just because it is good (although that helps), but because of market forces; marketing in particular.

Thanks to the jgauffin for the inspiration behind this post.