Welcome to this week’s Friday with Filip!
There’s a saying that goes like this:
Use the right tool for the right job
Even if you find the right tool for your job, do you know how to use the tool correctly?
This is exactly what I want to talk about this Friday; you need to know your tools in order for you to know it’s the right tool for this job!
Do you know your tooling?
All too often I see developers using amazing new tools but in many cases not knowing the limits or how to use it correctly. It’s very important to understand how to use a tool and what the implications of using a tool in a certain way has. When I find a new tool or a new library that I want to use, I try to research it and understand it before I recommend it for production use.
To me a tool is not only a software that I run or a hammer that I use, but I also consider a third party library a tool. A tool for me is something that I use to solve a certain problem and smaller parts can build a larger tool.
Problems with not knowing your tools
If you don’t know what your tool does behind the scenes you can get very big problems in the end. If you try to use a hammer to screw something into the wall there might be an easy work around just to hammer the screw into the wall. But what if it was the other way around?
Imagine that you had a screwdriver but a nail that you had to put into a plank; getting that into the plank would be much harder, no?
It’s still possible of course to solve the problem by just using the other end of the screwdriver and hammer the nail slowly into the plank.
So where am I going with this?
If you use a library or software that is new and hype which solves a certain problem but makes it harder for you; maybe you’re doing it wrong! The tooling might be great for solving one of the problems, but the way that you use it just gives you too much of a headache. If you go back and do some research on the tools, you might find that you are using it wrong or that the tool simply is not for the specific use case.
A good example here is LINQ to EF. I’ve seen many developers knowing how to use LINQ but not knowing what happens behind the scenes. This can be very dangerous for the performance of your application.
One other problem that arises with this is that most of us test our applications with very little data in it, but in a real world application after some time there might be a lot more data to process which was not considered at the beginning.
Now to be a bit more concrete, see of the following LINQ to EF query:
var persons = from person in db.Persons
where person.Name.Contains("Filip")
select person;
This can of course be written like this as well:
var persons = db.Persons.Where(person => person.Name.Contains("Filip");
Both of these will be executed as soon as you request the result by doing persons.ToList(); for instance.
This all looks very good, it might be exactly what we want to do as well. But what happens if we have 1 billion persons in our database?
The SQL query that is generated from this will perform what is called a row search, which means it does not use any indexing which means it will have to go over 1 billion persons and do a search within each person’s name.
Consider that it generated the following SQL:
SELECT * FROM Persons WHERE Name LIKE '%Filip%';
Of course we can optimize this by using full text search! But that is not the point, the point is that we might not have considered that Contains() will actually be a slow operation to run. If we knew that this would skip all indexes we might had chosen to use StartsWith() instead.
Another problem with not knowing how LINQ works internally is that all too often I see developers doing ToList() just because they want to use the types in .NET instead of having it translated to SQL. If they had known of EntityFunctions or SqlFunctions they might had chosen to run the query on the database side instead of doing LINQ to Object!
Because if we perform the query below, we will actually fetch the 1 billion rows from the database and have them in memory and then perform the search in the application instead.
db.Persons.ToList().Where(person => person.Name.StartsWith("Filip").ToList();
Again, if we know our tooling and use the right tool for the right job, we are going to do a much better job.
Do you know your tools?
Vote on HN
Welcome to this week’s Friday with Filip!
Last week I shared the first part in a very interesting session that I had the pleasure to do with Patrick over at NDepend. Having readable code and manageable solutions is very important but in some cases small changes that might see, trivial to you, might not be as trivial to someone else.
If you had to keep track of all dependencies in your head you are not going to have anything else on your mind; which is a pretty bad way to distribute your brain! Instead of keeping it all in your head, you can use a tool like NDepend to find out a lot of interesting things about your projects. If you’ve seen the previous posts and videos that I have done on NDepend, you know what kind of power this tool delivers.
The webinars that I have had the pleasure to do with Patrick has been very educating and I hope you like them as well, I would love to get some feedback!
So this week we are going to dig deeper with NDepend and spot dependencies, dependency cycles and spaghetti code! As we look on mscorlib, you can see that in some cases bi-directional dependencies are by design, but in other cases it might have been accidental. Sit back and enjoy the two parts below!
Part 2
Keeping our code base clean and understandable is important and as you might have seen now, there are tools that can help us along the way.
What are your tips on the subject?
Vote on HN
Welcome to this week’s Friday with Filip!
Two weeks ago we looked at Dealing with Code Complexity using NDepend. This was the first episode in the webinar series on Code Quality.
This week I am happy to share that Patrick Smacchia and I have recorded the second episode! This week it’s about dependencies, dependency cycles and spaghetti code. I really enjoyed doing these sessions with Patrick and I really hope you will enjoy it just as much. Let me know what you think of it!
Vote on HN
Technology have been a big part of my life ever since I was a kid. If it wasn’t a console it was a computer and later came the mobile phone. All these things running on electricity have always interested me. My first mobile phone was a Nokia 5110, which is the only phone that actually never broke.
There’s a joke around the net that the old Nokia phones never broke and that’s very true; however they didn’t do much more than calls, sms and snake.
When the phones with color displays appeared the mobile vendors noticed that people wanted to switch phones often; as soon as a new feature was released everyone had to have it. The vendors immediately started pushing out more and more phones, a lot more phones than were actually needed on the market. With this overwhelming amount of mobile phones and rapid development came a lot of more bugs.
Since I swapped from my first Nokia phone, I haven’t had a single phone for more than 1 – 2 years. This isn’t because I really needed to get a new phone but because after a long period of time it started feeling slow, less responsive and lacked all the cool features the new phones had. If the consumers want to buy new phones every second year, why should the vendors make phones that work for more than 2 years?
This has gotten too far, I’m not talking about the mobile phones but technology in general; the consumers are expected to change their behavior and their hardware/software often (every 1-2 years). What’s scary about this is that I’ve caught myself saying:
Oh, you’ve got the 2 year old version/model. That program/accessory doesn’t work on that version/model. You need to upgrade.
As consumers have somewhat adapted to this and expect rapid updates for software’s. The vendors no longer need to spend as much time on finding bugs as they did before. A very good example of this is the launch of Diablo 3 where Blizzard needed to push Diablo 3 to the customers without it being completely finished. If you played Diablo 3 when it first arrived and play it today, it’s almost as you play 2 completely different games; the story the same, but other things have changed.
It is not rare that vendors have open-betas of their in-development software or hardware. In Office 2013, Microsoft added an “instant feedback button” and this is Great! However, I’ve seen a lot of software’s where they “forgot” to remove the “report a bug”-button in the RTM (release to manufacturing). Of course it should be easy to report a bug once you find it, but nowadays it’s pretty much like the vendors expect the users to find bugs and that they need rapid ways to report these.
We no longer see bugs as exceptions, but it’s rather expected and when we do find a bug we immediately think “this will be fixed in the next version sometime this week”.
Stop delivering less than awesome software
We’ve seen that consumers are not scared of changing their behavior, as that’s what we do; we adapt. Vendors need to start delivering better software and hardware!
As a software engineer, I know what I can do to ensure that each piece in the software that I create is high quality. If you don’t feel that you’ve done an awesome job, something is wrong; we need to be proud of the software that we deliver!
It’s quite often that bugs derive from “quick fixes”, but a quick fix can turn into a quickly evolving bug.
Here’s what I suggest we do to ensure quality of things we deliver:
- Test, test and TEST!
- Refactor your code according to the programming guidelines of the language your using
- Write documentation (even if short!) about your methods, flow and functionality
- Write test documents which includes both manual and automated tests
- Create automated UI tests
- Run complexity analysis tools such as NDepend on the code base to find too complex areas
- Don’t deliver if you’re not happy with the outcome
- Write readable code
- Don’t try to optimize better than your compile can by writing complex and un-readable code
- Drink a cup of coffee before you deploy
Let’s make better software, together!
What’s your suggestion on ensuring that we deliver high quality?
Vote on HN
Filip Ekberg is a Senior Software Engineer working in the country with all the polar bears, author of a self-published C# programming book and overall in love with programming.
