Monday, September 13, 2010

Testers vs. Developers

Some time ago I read somewhere that Microsoft had problems getting software testers in Denmark. They were puzzled by this as they found the workforce to be educated and they had no trouble finding developers.


Although testers and developers should share some common knowledge of technology, their personalities are completely different. Good developers need to be inovative to be able to find solutions to problem they have never seen before. They should focus on the big picture and always strive for the best compromise. Good testers on the other hand have to focus on details and they need to be able to repeat an exact action and follow a script. The qualities wanted are opposites and it will most likely never be possible to find a person that posseses both.

Links:



http://www.version2.dk/artikel/14884-test-er-fy-ord-i-jobannoncer-microsoft-kan-ikke-hyre-danske-software-testere

Friday, August 06, 2010

5 years and still going

Yesterday it was 5 years since I started this blog. I started it because I needed somewhere to let steam out. (And I actually started it together with a friend) I wasn't sure I would be able to continue posting to it but after 5 years I still have issues I want to share (with myself). Luckily the world never stops changing and I never stop discovering things I hadn't thought of before.

The focus has been from very technical to philosofical about human nature. I'm looking forward for all the new blogpost that I am to write :)

Wednesday, June 23, 2010

Trust me, I know what I'm doing

Trust is important to any social relationship or communication. While I was out for a run I listened to a podcast about this and it really made me think. It stated that trust is also good for business. If you trust your surroundings you will be more open for doing business. Societies based on trust have a higher growth than societies that do not incorporate trust. This is a great message that I will try to spread around.

On a personal level you will gain a lot by trusting other people as well. By doing so you can benefit a lot more from other people. If you for instance are an employer, but don't trust your employees the only value they can add to your organisation is doing the stuff you though of to begin with. Once you trust your employees, they will be able to add value to your organisation on their own. You will no longer have to supervise them and they will be able to inovate. They will have to take ownership and it will lead to a higher level of motivation.

Actually you should not trust me because I know what I am doing. You should trust me because it is in my best interrest to help you out and because you will benefit more if you let me do it my way.

Related posts:
http://dotnetexception.blogspot.com/2010/04/leadership-is-about-motivation.html
http://dotnetexception.blogspot.com/2009/11/flank-your-problems.html
http://dotnetexception.blogspot.com/2010/01/there-is-no-such-thing-as-perfect.html
http://dotnetexception.blogspot.com/2009/03/misunderstanding-path-to-new-ideas.html

Friday, May 14, 2010

Discuss this!

I have categorized discussions in 4 groups

Religious
When in the context of a religion, the main goal of a discussion is to reach an already given conclusion. Any valid arguments are discharted if they contradict the given conclusion.
This kind of discussion is often held by religious people such as evangelists (the software kind too) or sales people. It's also the favorite form for drunk people trying to argue that they are not drunk.
Religious discussions also occur if you are too specialized. If the only tool you know how to use is a hammer, you are bound to use a hammer to solve every problem.

Philosophical
These are discussions without a goal. That might sound useless, but it's not that bad at all. It's about questioning your own beliefs.
It's a mind opener. It's about challenging your ideas, getting the big picture.

Scientific
The scientific discussion is about reducing the complexity of a domain. The conclusions might be inaccurate, but it should result in the optimal solution all things considered. Issues like feasibility and return of investment are handled in these discussions as well as risks. It should be noted that a conclusion concluded today, might me changed tomorrow. Scientific discussions embrace and accept change.

Lawful
Law is about details. The more the merrier. When you reach the maximum amount of details any human can comprehend, you are about half way there. The downside is that often the big picture and reasoning is lost in the pursuit for details. Although the focus is on details, even the details are sometimes lost in discussions like that. The last man standing is the one with photographic memory and who can stay awake the longest. To succeed in this category I suggest that you give up on any social life and start nit picking on your surroundings. Although there can be a winner in such a discussion, the real looser is the common sense and productivity.
Law is a primal discussion form and we are trained to master it when we have arguments in kindergarten about what is right and wrong and which kid has more candy (milimeterdemokrati).


When it comes to software development, you might have these different discussions at different points of time on your project. The religious discussions occur in the beginning of a project, or when changes to the project occur. Although the religious debate has a high return in the short term, the long term might suffer.
As the philosophical discussion is about challenging your current beliefs, it's great for workshops or when a project is stuck in a dead end.
The scientific discussion is great for decision making on a project. What separates a decision derived from a scientific discussion from a religious discussion is the scope.
The lawful discussion comes into play on a software project when someone feels he's not treated right. The discussion often can't be resolved by the parties involved and a third party is then required.

Let the discussions begin!

Tuesday, April 13, 2010

Change the world, bit by bit

Although you meet resistance, you should still still keep on trying to change the world.

When it comes to software you are often met with statements like:

  • This technology is going to be a mayor player.
  • Its a strategic decission to use this product.
  • Thats what the client wants.


If you are a software developer and know better than what has been presented to you, you should share this knowledge. If we let the world evolve by the words of marketing people, complexity will keep on increasing, with out any innovation. If you want to help reducing complexity, please do let the people around you know when they are mistaken.

Monday, April 12, 2010

Hierarchy of Information

Most enterprise software solutions deals with data. Actually I can't think of any that don't. Many enterprise solutions deal with lots of data. The application helps the user to deal with these massive amounts of data.

I think of different levels of information. Each level decreases in size, but increases in value. Data in its lowest level is not very valuable. A bit or a byte of data is quite useless out of context. When characters are added together to form a string, the value increases significantly. A string in the form of a sentence is easier to remember than a equally amount of random bytes. The amount of information has decreased, but its value has increased. We are now able to compress the information to something smaller. Raw data is refined to information, knowledge and wisdom.








The Earth computer in The Hitchhiker's Guide To The Galaxy is the ultimate example of this refinement of information. All the information in the world is refined to the very short and easy to remember result: "42". If this was not fiction, this result would be the single most valuable piece of information.


Every business strives to find the secrets of making lots of money( or save the planet ), and every business application is build to expose these secrets.

Wednesday, April 07, 2010

Somebody has been reading my mind

This december I won a book (actually I won four, but the other ones were just not as great) in a technology contest. I don't know how I have missed out on this one. I have seen it on the booksshelfes but I have not read it until now. I must say that its brilliant. "The Pragmatic Programmer" is a pleasure to read.


The Pragmatic programmer is about thinking while you develop. It  promotes the obvious that is apparently not as obvious as we thought. Its as if the authors read my blog posts before I even wrote them :) This book really makes you think and I hope I can get my current collegues as well as future ones to read this so they can reflect a little about their actions.

Tuesday, April 06, 2010

Leadership is about motivation

Leadership is not a simple task, but I think you will come far if you focus on motivation.

How to motivate while you lead can be done in a number of ways. The first step is of course to understand your teammembers. Find out what makes them tick.
I think the best way to go is to find common interests and focus on that. Knowing the persons on your team makes it easier to find something that will naturally interest the individual.

Cool cash
This an easy way to motivate people. Money is a fundamental requirement for everybody. The problem with this is thats if this is your only motivator you can easily be outbid by others.
If we reflect this to training a dog this resemples giving your dog treats when it does what you tell it to. It will work as long as the dog is hungry and likes your treats. If someone shows up with better treats you have lost.

Fear
This is the opposite of the Cool Cash motivator. This is where you punish people if they don't do as they are told. This method has worked like a charm for many dictators in the past. The downside is that there can't be any alternatives to your leadership, and thats not easy to enforce in todays society. This works best if you have an uneducated workforce.
In dog training this resembles beating your dog untill it does it right.

Common interests
You need emphathy to succed with this one. You need to understand what drives the people working for you. If your workforce matches the tasks you have, it's going to be easy. They will more or less do it right whatever you say. This is about choosing the right team for the job. If you need to herd sheep, choosing a hunting dog would be a bad choice.

Once you have your team put together you need to know what drives your team members. Some people strive for acknowledgement by coworkers, some live by the shear technology challenge presented to them and other people strive by other things. It's important to realize that motivation is not just important as to maximize output by your team. If you don't know how to motivate your team, it will collapse. And chances are that it will influence other parts of your business.
In dog world this resembles: If you have a herd dog and don't provide stimuli, it will take your house apart.

Monday, March 22, 2010

Plans are just for a general direction

By now, it must be clear to most people in the software industry that software projects seldomly go as planned.

There is a lot of debate in Denmark about
large govermental IT projects that fail. It would have surprised me more if they didn't fail. They are large project with a vast number of details that must all be fullfilled for the projects to succeed. That's just not a realistic scenario.

An IT software project is about inovation and not about building something already known. If you encounter a bump on the way on the road, you shouldn't have to force your way through it if there is a more sensible way around that was not part of the project to begin with. There's bound to be some experimentation going on during any project and you must be able to change the requirements along the way as the parties involved get smarter and discover things about the domain at hand.

These days, the role of the project manager isn't to keep the project on track, but find a way when changes to the requirement ocur (not if, when).
If an IT software project is to support change, it's needless to say that it requires a lot of involvement from the client (the buyer of the project). You can't order some software that takes 3 years to build and expect it to be like you imagined it to be if it is build solely based on a document you wrote to begin with. If you want to benefit from a project you have to get your fingers dirty yourself.

Friday, March 19, 2010

Being disposable is a goal in it self

Your true value is shown if you are disposable and still have a job. This means that your work is actually appreciated. If you kling on to your job by having a bunch of old applications that just don't work unless you're around, then in my opinion you have failed.

The same goes with the applications that you make. If you make applications that depend on your future presence you are just gathering new responsebilities along the way. In the end you are not going to be inovative because your past will haunt you.

Wednesday, February 24, 2010

SAAS vs. thick client

The other day my work computer crashed. I took me quite a while to get up to speed. The IT department ofcourse provides a standard image they can put on my computer and get me part of the way. The programs I depend on and the antivirus provided are not good friends so I chose to install the computer on my own.

So... I'm down to installing the operating system, installing different office products to read documents and some development tools. A lot of time is spend finding the programs i need, and finding licence keys that match. After a days I'm still missing some programs that I will need later. Its a long and slow proccess...

Why does commercial software need to be so troublesome to install?.

If I could do with open source tools (thats not an option) i'm sure I could have set up an ubuntu with all the packages in an hour or so. I wouldn't have to find and download the software i need and I wouldn't have the trouble of typing in keys and trying to activate them and find out why they didn't activate properly.

For my personal stuff I have moved everything to google apps. This means that once I have a browser up and running I'm good to go. This and the fact that I don't have to think about backups etc. is a sure winner for me!

Saturday, February 20, 2010

Predictability is a key feature

You can run a rally car on ice. You can travel under water. You can create a fast program based on slow components.

This is all due to predictability. While racing on ice you know more or less what friction you will get and what it will take to change direction. You will know how far you need to see ahead to be able to stay on track. If that criteria is met you can go as fast as possible.

On the oter hand, if you are racing on a mixed surface, you have to go slower. While you have traction you have to drive with a big margin to be able to control your skid if you suddently loose traction. While you lack traction you have to drive slower because if you skid around the corners and reach a high friction area you will end up in the ditch. Given the choice I would definately choose the high predictablity over max traction.

If you know all the parameters of a software project up front you are pretty safe. If you know all the parameters up front, you will also be the first in history to do so. Are you so sure of your requiremetns that you can choose components that fulfill your requirements but are not flexible enought to handle requirement changes? Are you so sure of your performance demands that you  can choose components that perform well but don't scale if your demands change?

Flexibility is often a an underrated feature. Its hard to put in sales brochures. Its hard to tell customers that the extra cost is to support their requirements in the future that they are not aware of yet. Often it has to do with how mature an IT project organisation you are dealing with. The more mature it is, the greater the chance of it expecting changes in the future and the more flexibility it wants from its IT systems. My experience is that these changes will amerge before the end of the project and the flexibility will end up saving them money before the project has ended.

Tuesday, February 16, 2010

Whats your projects focus?


My diagram illustrates the focus in a project. The blue on the left hand side is the business and the red on the right is the techonolgy focus on a project. The focus on any technology project will go from somewhere on the left towards the right.

In the 'A' section focus is on the business processes. Its The Why of the project. This is where you have to justify the business processes. Are the business processes really business processes or are they in fact based on limitations in old systems. If there are any mayor improvements to the busines process, this is the place to discover them.

In the 'B' section business and technology are equally important. Its The How of the project. This is where you figure out the technical specifications for the project. There might be some adjustments to the business to make it feasible.

In 'C' its mostly about technology. Its The Where of the project. Here there is little you can do to the business. You just have to implement the stuff that has been decided.

A mistake I have seen on a lot of projects is that they focus on technology. They skip to "The How" or "The Where". They haven't realized that the real benefit from technology comes when you also change the way you operate and the way you think. The reason for skipping "The Why" is often that they claim its a technology project and they already know about their business. Some people are actually offended if you suggest improvements to the way they work. Its very sad to be on such a project.

Many projects I have worked on are based on contracts that include a lot of requirements. If they have not recieved guidance in making these requirements, they have missed out on a lot of possible proccess improvements. If your project is all in the C section the benefits from the project will be minimal, and the project will be more or less pointless.

My recommendation is to keep the focus as far to the left as human possible. Thats where the sweet honey is :)

The diagram can also be applied to technical documentation or books. They will and should start by outlining what it is all about. As you proceed through the text it will focus more and more on the technology. For me I find the first half of a technical book easier to read than the last half.

Sunday, February 07, 2010

HTML5 to the resque!

I have previously written that I was disappointed with silverlight as a platform for rich user interfaces in a browser. It probably has a lot of nice features, but as a web technology it's not really important if it is not platform independant.

I went to see a demonstration of HTML5 the other day. I don't think there is much you can do in Silverlight or Flash that you can't do in HTML5. Silverlight and Flash are bound to fade out and their domain is going to be taken over by HTML5.

Internet Explorer is currently the only mayor browser not supporting HTML5. You can however install a plugin that will allow HTML5 to be displayed correctly.

Friday, January 29, 2010

Being a Generalist

Thats me!

I dream in abstracts and concepts and avoid anything with substance.

Some people like using their time getting better at what they already know. I seldomly have more than one book on a subject and have a hard time focussing on a single issue long enough to get any real experience with it. As soon as I have basic knowledge of a subject I tend to move on. This doesn't mean that I don't have a lot of books or isn't constantly on the lookout for new input. Au contraire.

If we take databases as an example. My interest stops at tables and what you can do with ANSI SQL. What features each database implementation has is not really important to me. I can look that up if I need it later.

The disadvantage of this approach is that I'm dependend on my team to complete anything. Luckily I like working together with people.

The advantage is that the knowledge I gather isn't easily outdated and it can therefore accumulate over time. In other words I don't have to start from scratch every other year by learning new technologies.

Thursday, January 28, 2010

To Cloud or not to Cloud, thats not even a real question

I have read a few posts about Cloud computing on the net. Some of them show great fear of this new thing where a computer is not just a computer and a program is not just a program. How do you back up data and how do you keep it away from others?

To me cloud computing is about abstracting away from hardware instances and thereby allowing easier scalling and distribution of computing. Cloud computing is to instance computing as functional programming is to imperative programming or SOA is to system integration. Instead of defining how you want it you must define what the needs of the application are. This could turn out to be a lot more productive than what we have been used to.

I don't nescesarily think that if you go the Cloud way you have to place all of your data somewhere out of control. It might very well be that parts of your application needs to scale well and you can put that part on a Cloud that supports this. Other parts of you application that has other requirements might have to be put elsewhere, maybe even on the cloud on your own network.

Having few dependencies has been a goal in software development for a long time, and now its moving to the hardware platform. This is a good thing as application requirements will hopefuly be much more transparent in the future.

Tuesday, January 19, 2010

There is no such thing as perfect

You might think you are the exeption to this. You aren't! :)

So, what am I saying: that perfectionists are wasting their time getting everything perfect...  Yes, in my opinion they are for sure mising out on a lot of creativity, and they won't achieve their goal anyway.

As I see it the result of what you do can be illustrated as the following graph.




It illustrates the time it takes to reach perfection. Actually it show that you will never reach perfection. Productivity is the angle on the curve. In the beginning you are going very fast towards the goal. As you acomplish things your focus will change from fundamental structural task into details.

The strive for perfection is often a sign of lack of experience.

Tuesday, January 12, 2010

Password nightmare

If you are employed in any modern company there will be plenty of applications you need access to.

At the moment I have to remember 7 passwords for different systems just to be able to do my daily work. On top of that I have to access systems on several client's networks and I must admit that I can't keep up any more. All systems have different algoritms for what passwords they accept and they all have different timeschedules for when I have to change the passwords.

All the systems are created and configured with the best intensions but the sum of the systems is a security disaster. There is no system more secure than its weakest link, and I'm sad to say, thats me.

Every time its possible I tend to breach security policies by having passwords I can remember or writting the passwords down somewhere else.

Monday, January 04, 2010

Size does matter!

Its true. Maybe I should be more precise and say that code size matters.

Which is more readable of the following?



or


They both show the same code sample I nicked from the internet, and they both display the same number of lines.
The first one is the recomended style for C#. The second is more like Suns recommendations for Java.

The first sample uses a lot of lines for syntax. This means that you actually can't see the whole method without scrolling the window down. This is one of the reasons I prefer the second approach. The blank lines just bloats the code and makes it harder to view the code as a whole. Although I generally think formatting of code is of little importance to a project, there is no reason to have extra lines that contain no extra information.