Archive

Archive for the ‘Software engineering’ Category

Quality isn’t a tool–You can’t install it!

June 20th, 2012 13 comments

time, quality and money conceptDid you ask yourself why a team in an organization produces very good software quality and another team in the same organization just struggles to get things done and those things are in really bad quality? Interesting is also that for both teams exists the same rules (methologies, procedures, tools, frameworks, etc.). But why could and does this happen?

Some people – mostly managers or vendors – try to distill quality to a recipe. Vendors could sell it expensively (with consulting) and managers can buy it to prove their bosses that they didn’t make something wrong (they used the standard procedures and tools). This whole thing is ridiculous, also because it happens again and again (also with agile practices).

So, you can’t buy quality, neither you can install it in your team or organization. Also it isn’t a tool, which makes the quality (many managers think that frameworks guarantee quality, which is completely wrong). But why can one team be so much better than another one? So we are back to my question at the beginning of this blog post.

The only reason for this difference are the people. The people or some of them in the good team care about their profession. So they keep up-to-date (read blogs, articles, books, etc.) and leads other team members to become better. But the one of the most important things is unfortunately discipline. So you have to improve yourself constantly (keep you out of the comfort zone) and look always for improvements for you and your team. And yes, that isn’t easy.

Once you are one of those people, be aware of being dogmatic, just stay pragmatic but insist on the important principles as long your arguments are reasonable.

And the managers? If they are not able to change themselves (especially the middle management), then it’s up to you to change the organization – it’s your career and life.

Share

Anti-Pattern ‘Validation by Execute ‘n’ Rollback’

February 21st, 2012 1 comment

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();
		}
	}
}

Fotolia_20233238_SThe 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.

Share
Categories: Anti patterns, Software engineering Tags:

Who should make decisions about technologies?

February 13th, 2012 No comments

Stay on courseOne 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.

Share

Speaking at the .NET Usergroup Bern

December 4th, 2011 No comments

imageDuring a Lunch event organized by the .NET Usergroup Bern at the 7 December 2011 in Bern I will speak about the following question:

Is Software design overrated?

Yes, I know, it’s provocative. And obviously wrong. Really? I’m not so sure. After 10 years as software engineer and some years as software architect I saw too often no design, just a transformation from requirements directly in code. And what is the problem with that?

Interested? So come to my talk, here is some more information. The twitter hashtag will be #dnugbesd.

Share

Speaking at the .NET Usergroup Zentralschweiz

November 18th, 2011 No comments

dotnetzentralI’m holding at the .NET Usergroup Zentralschweiz a short talk about "Know your warm-up", see my last blog post. I’ll explain what I developed exactly and how I train new employees with this warm-up. I will also demonstrate the sample application which a new employee develops from scratch.

Come to see me speaking the 24. November, 18:00 at the following address: bbv Software Service AG, Blumenrain 10, Luzern, 1. Stock.

Thanks @danielmarbach and @ursenzler for having me.

Update:
There is a wrap-up on the site of the .NET Usergroup Zentralschweiz with some pictures. The slides are now available.

Share