assumption of advancement

When you’re a software engineer who produces software for enterprises like banks or assurances, then it is normal you have huge databases (several gigabytes). Such systems have an operative application where users do the daily business of the company and there are more informative parts (or strategic parts) of the systems which the management uses. At a first glance, there isn’t a problem with those two views, but as you probably know, those companies have for the second part for the management a data ware house solution.

But what if your customer doesn’t want a data ware house solution? Or if he couldn’t afford one? Then you will probably add reports, search views to your application. In this blog post I describe some of the aspects if you’ve to choose this variation.

Stale data as a requirement

Unfortunately the question "how old can the data on this report/search be?" is rarely asked. When the answer is "The report/search has to show the right data", then you have to ask the customer again. The problem is, the data is maybe already stale after the query, because somebody changed some data.

In my experience there are only a few reports, which need as little as possible stale data. But it is essential that you ask this question.

Isolate only as far as needed

Most searches or reports need essential tables in your relational database, so it is important that those searches or reports don’t have an effect to your daily business. You ask yourself maybe now, how those queries could have any impact?

If you use Microsoft SQL Server, then the default isolation level is "Read committed". If a query isn’t that clever made, it could happen, that the query blocks a whole table (Intended Shared Lock which blocks any inserts or updates). If that happen, your users will remark that by waiting while they try to save their data.

When you create a search or an report you have to ask yourself always, which Isolation level you will use. When you use dirty reads (Isolation level "Read uncommitted"), then you’ll probably never generate any locks, but you have to deal with data which is wrong. This because data could be roll backed and the same query wouldn’t bring the roll backed data again.

Conclusion

Stale data or even wrong data on a search or an informational report hasn’t to be wrong or a mistake. Sometimes it’s just good enough to fulfil the requirements and make the customer happy. And that’s what it’s all about.

If you like this, follow me on twitter…

Recently in some reviews I saw an anti-pattern. First you have to know, in the code, there was a validation of the data before it was stored in the database. So far so good. But when I looked at the validation code, I saw the following:

public void Validate()
{
	DoProcess(true);
}

And the persist logic (with some business logic) looked like this:

public void Process()
{
	DoProcess(false);
}

So, I asked myself, what the Boolean means. Well, here is the method signature:

public void DoProcess(bool bValidate)

Hmm, the code looks quite magic so far and the argument (and the method name) itself is more or less an anti-pattern already. But when I checked the DoProcess method, I saw something more or less like this:

public void DoProcess(bool bValidate)
{
	using (SqlConnection con = new SqlConnection(connectionString))
	{
		con.Open();
		SqlTransaction transaction = con.BeginTransaction();

		// Some business logic here...

		if(bValidate)
		{
			transaction.Rollback();
		}
		else
		{
			transaction.Commit();
		}
	}
}

The idea behind this code is, if it could be executed successfully, that means a successful validation. If there are any problems during the execution, those problems are the result of the validation. The execution itself wouldn’t be a problem after a successful validation (now I need a drink…).

Doing it better

It’s easy to find bad things, but it’s sometimes harder to do things right. But in this case, the better way is easy. First, you have to separate your business logic from the data access logic. This means following the separation of concern principle.

The next point is, that you’re able to validate your model. So put the logic where it should be. If you use a domain model, the logic to validate an entity has to be on that entity. Or if you have a table module approach, the logic to validate an entity has to be on the corresponding table module.

Side effects

There are also other problems with this anti-pattern. There are some side effects with the data.

As you know, transactions should be as short as possible to prevent lock problems with your data. But if you have combined the business logic and data access logic, your transactions are much longer than needed. To make it worse, this anti-pattern forces you to do it at least twice.

There are reasonable use cases for dirty reads: For example fast searches. In this case you accept dirty reads and you don’t want any locks on your data in the database. Normally, the chance to have a dirty read isn’t that high, but with this anti-pattern the chances to get a dirty read are significantly higher.

If you like this, follow me on twitter…

One of the biggest problems of software engineering companies in Switzerland is currently to get new software developers. To get new employees there are several points as for example salary, environment, career possibilities and technologies. The last point looks easy but in reality it isn’t that easy. Why are essential technology decisions (like languages, frameworks, application servers or big libraries) not only made by developers? Why does the management mostly make those decisions?

In this blog post I try to see the technology aspect for creating software from different perspectives. Those views based on experiences and talks I had during the last ten years.

Customer

As expected the technology used for the software is for the customer irrelevant. But for him counts the working functionality and some non-functional requirements as usability or performance.

Product owner or product manager

The product owner neither is interested in the used technology directly. He’s mainly interested to get the functionality in time and in budget. But he’s also interested to get a good quality of the product, else he’ll receive complaints from the users (of the customer).

IT department

The IT department who has to operate the system is somehow interested in technology. They usually don’t like new technology. One reason is for sure "never change a running system". Another reason is the needed knowhow for every technology. They have to concern the cost of maintaining that knowhow.

Software Architect

The software architect (and I am currently one) is special. When he’s interested in technology, he should take responsibility in the project. If not, you have an architect who lives in the "ivory tower". Mainly the architect should concern more about structure, integration of components or other systems, maintainability and quality.

Human resource management

In most of the companies this part get lost. Today it is hard (specially in Switzerland) to get new developers. So, new and fancy technologies make a job or company more attractive. This means, that the human resource management is interested to use up-to-date technologies.

Developer

Well, most developers care about technology. Specially younger developers more because they had the possibility to try those at the university or in little projects with their colleagues. For those developers technology is essential for the daily job and to be motivated. If they have not the possibility to use new technology they will leave the company after one or two years. And that isn’t cheap for the company.

Management

Today most companies use some self-made frameworks. One reason they spent money to create one is the fear of creative developers who want "to fulfil themself". This means for the management that those developers are out of control and create overcomplicated things with a lot of different technologies. I think this fear is unjustified today, but in the days when everybody could call himself a developer it was not only rightless.
But the management has the difficult task to concern all the roles I described before and make a reasonably decision.

Conclusion

It seams there is a fight between the developers and the management who should make decisions about technologies. It is important that the management has all the information it needs and can concern all the risks of an introduction of a new technology. But the management has to be open to all the facts and arguments and should not presume to make a decision based on old experiences, assumptions or prejudices.
If the decisions are too offensive, then you have at the end quite everything in the IT department (for example all java application server products). On the other hand, if the decisions are too defensive, then you will have a stagnation. This will be very expensive to solve because you have to spend a lot of many to get up-to-date again.

If you like this, follow me on twitter…

When you’ve to use TFS, then there are moments when you’re missing some features in the UI tools in Visual Studio. In those situations the console tool tf.exe is very useful. In this short blog post I summarized the commands I used the most.

Update an old version of a branch

It could happen, that the production branch or an older feature branch isn’t up-to-date, because somebody forgot one or several merges from the main branch. To fix that, there could be used the following statement:

tf.exe merge /recursive /force /version:T $/Project/Main/Source $/Project/Production/Source

Delete a branch permanently

After a while the number of merged feature branches increase. Normally, you would delete the merged feature branches, so they aren’t any longer visible in Visual Studio. But in my case, I display also the deleted items and this means, that I see all the deleted feature branches. To remove the old merged feature branches, there could be used the following statement:

tf.exe destroy $/Project/Development/FeatureX

If you like this, follow me on twitter…

I do a lot of trainings and courses in the company where I work currently. And I was also in a lot of courses too. But I think, that those courses or trainings don’t work really. The reason, why is that they are just so called "sheep dips".

Sheep dip training doesn’t work

The first time when I heard the expression "sheep dip" was in the excellent book "Pragmatic Thinking and Learning". It means a training where a lot of people receive a lot of information, mostly just by sitting, listening and watching a lot of PowerPoint slides.

A sheep dip is in real the following (from "Pragmatic Thinking & Learning"):

A sheep dip (for real) is a large tank in which you dunk the unsuspecting
sheep to clean them up and rid them of parasites (see picture). The sheep line up (as sheep do) you grab one and dunk in the tank for an intensive, alien, and largely toxic experience. It wears off, of course, so you have to dip them again.

The problem is the exact same with the education trainings in companies. A lot of employees spend time and the revenue is very, very little.

Doing it better

The question is "How can we do education better?". In my experience there are some better ways:

• Pair programming
• Little workshops (just the team)
• Collaboration platforms
• Good documentation

One of the best ways to learn is to get feedback fast. In a "sheep dip" training/course there is nearly no chance to have a such feedback. Therefor pair programming is very good, but hard to do. At least one of the two developers has to be experienced, so the knowledge transfer could happen.

Another way I like very much are little workshops. Normally I ask a developer team, if they are interested in some kind of workshops (reviews, designing, architecture, etc.) based on some reviews of their outcome. The feedback what I received so far is very positive.

I think collaboration platforms, like wikis or OneNote, are still underestimated in corporate environments. But I had a chance to participate in a team where they used OneNote. It was really great, because they added all little tricks and tips how to handle problems with the frameworks and tools in this collaborative platform.

The last way is a good documentation. But what is a good documentation? Well, for me it has to be up-do-date, clear, short, contains examples and easy to read. Another point is, that the documentation has to be searchable. It should be easy to find things fast and just in one place.

If you like this, follow me on twitter…