Each week I write a blog post which describes what I learned that week. I write these blog posts for two reasons.
First, I want to keep track of my personal development and writing regular blog posts is a great way to do it.
Second, I want to share my findings with you. I hope that you can use some of them in your daily work.
Let's get started and find out what I learned in week 43.
What I Learned in Week 43
First, Generate enough dummy data.
Sometimes the performance problems of an application are noticed when the application is deployed to the production environment. This is a bad situation because it can have seismic consequences.
If this happens to you, it means that you have not done your job!
Because you probably don't want to look like an ass, you have to generate enough dummy data which is used during the development phase. Remember to follow these guidelines:
- The amount of required data depends from the your requirements. If the performance requirements of the application are vague, it is your responsibility to refine those requirements into something concrete. If you don't find out the exact performance requirements, you can be sure that it will bite you in the ass later.
- The generation of dummy data must be both easy and fast. If the generations is hard or it takes too long, the odds are that the developers might not do it.
- The generation of dummy data must be your top priority. It is often easy to skip this step because your customer wants you to start adding features to the application. Don't do this. It is your job to explain the benefits of dummy data generation to your customer and convince him to give a green light for this task.
Second, Run performance tests during the development phase.
If you have any common sense, you want to avoid running into performance problems when your application is deployed to the production environment. This means that your only option is to run performance tests before that is done.
Also, running performance tests only during acceptance testing is a horrible idea. The problem of this approach is that if performance problems are found during acceptance testing, fixing those problems can take a lot of time and money. Trust me, you don’t want to end up in this situation either.
You must find performance problems as soon as possible.
In other words, you have to run performance tests during the development phase. Remember that the sooner you find a problem, the easier it is to fix.
Third, Users will break your application by using it in unexpected way.
This week I received an interesting bug report concerning a function which I implemented about one and half years ago. This function has a form which allows the administrators to enter information by using two languages (Finnish and English).
When the form is submitted, the validation ensures that the information is entered by using at least one language.
When the user views the information, the application fetches the correct version by using the language preferred by the user. If the user hasn't set the preferred language, the Finnish version is shown. Guess what happens if an administrator enters only the English version to the database?
If the user hasn't set the preferred language or he has set it to Finnish, the application doesn't show him anything.
In other words, I screwed up.
Because the application is used by Finnish people, I couldn't imagine that someone would want to enter information by using only the English language. This problem was quite easy to fix but it taught me a very important lesson:
Expect the unexpected!
Fourth, Taking care of your competence is your responsibility.
There are no good discussion forums for Finnish IT professionals. There are a couple of forums which I check on a daily basis but they are often full of trolls. This week I noticed that many discussions had a link to a blog post called Why a career in computer programming sucks (I removed the link because the site went down. if you find a working mirror, let me know).
The authors of the posts which linked to that blog post claimed that it is impossible to have a long term career in computer programming because the lifespan of programming languages is too short. I have written about this before and it shouldn't be surprise to you that I disagree with these people.
I find it a bit absurd that someone expects that he can use programming language X for his entire career. Our industry still very young when compared to other more traditional engineering professions (I don't claim that software engineer is really engineering). That is why I think that it is only natural that the programming languages and other tools are evolving quite rapidly.
I think that we have to options:
- We can either adapt and learn those new programming languages and tools.
- We can bail out and stop writing software for living.
The most important thing that those people don't probably understand is this:
You are the only person who cares about your competence.
Your employer might offer you different ways to increase your competence but you are the only person who can decide whether you want to take advantage of these opportunities. Also, it is vital to understand that if your employer doesn't offer these opportunities to you, you have to take care of this yourself.
I know that this sounds a bit harsh, and I understand that it can be hard to find time to study if you have a family (or life outside your job).
However, I cannot understand how anyone can claim that someone else should be responsible of taking care of his competence.
It just doesn't make any sense!
Fifth, Hacking is so easy that even a child can do it.
This week a read a blog post by Troy Hunt which demonstrates that hacking is so that even a child can do it. In this blog post, Troy Hunt demonstrates how easy it is to hack websites by using the Havij SQL injection tool.
The video attached to the blog post is both funny and scary. It is funny because of his three years old son, and scary because it is so freaking easy to gather sensitive information from the hacked website.
This raises an interesting question:
When was the last time when you tried to hack your web application?
What Did You Learn This Week?
Share your learning experiences or other comments on the comment section.
"The authors of the posts which linked to that blog post claimed that it is impossible to have a long term career in computer programming because the lifespan of programming languages is too short."
That right there describes software developers without any passion about software development. My biggest problem with the field is that there's too many frameworks and languages that I want to play with, and only a finite amount of time to do so.
I have the same problem! I think that some people blame external circumstances because this way they don't have to think about the possibility that their own behavior might be a part of the problem.
Yeah, it's a sort of an entitlement. "I worked hard a long time ago to learn this, so I should be able to expect a lifetime career based on that initial work."
As an aside... I used to worry that, as I'd get older, I'd become less relevant as a software developer. In the past 5-10 years, I've seen how I've matured. I'm not worried anymore. When younger, it was always "I can rewrite this component on my own". As I've gotten older, I see that as a waste of time - I'm done with those technical challenges. There are plenty of open source frameworks out there now that take care of the routine work. With experience, you can pick the right components, fit them together efficiently, and really leverage other people's work.
Languages are the easy part. Frameworks are effort multipliers, and knowing how frameworks work and how they *should* work is real power. That translates across different platforms, and makes you valuable even when the job market switches to a new language - but that never happen overnight, anyway.
If you're stuck in an old language, refusing to change, and complaining about it, then your heart probably isn't in it anyway.
I gave this some more thought, then posted this: http://blakecaldwell.org/blog/2013/10/27/developing-software-in-a-changing-industry.html
"Fifth, Hacking is so easy that even a child can do it." That's why it's so important to check and validate your input data, mainly request params from users but also, developers usually forgot about check and validate data from database.
Unfortunately each time I tried to implement something like that I found a refusal from my colleagues and managers...
Did your colleagues and managers refuse because implementing validation would take too much time or did they have some other reasons for this?
Time, time, time and performance.....
Ah, the usual suspects :/