How to face the huge amount of changes in IT world (from a software developer perspective)

IT professionals, specially developers how are we supposed to deal with this huge amount of changes, new concepts, APIs, technologies… ???

1-Open mind: 

     The IT world is moving fast we should be open minded to accept changes. For example the old debate around ASP webforms VS ASP MVC  or  when Node.js came out many said that using javascript in both client side and server side is out of question (I don’t like programming in javascript either but it is not a reason to treat Node.js as a crap before even trying it).

We as developers we should know that there is no magic solution or silver bullet for everything, we should use the right tool ( i will use the word tool to represent concept, pattern, methodology, language,…) for the right job.

Simple example: personally I found Webforms more fitted to administrative pages than MVC, and MVC more suited for internet applications than Webforms. Node.Js is more suited for certain type of application like sending updates to user in real time (long-polling).

Even some design patterns may become useless over the time (depends on the context). 

Let's take the repository pattern  as example, we can find this pattern everywhere but did we really need it ??

This pattern came out before actual ORMs. ORMs are already based on this pattern so why adding additional abstractions specially for reads operations (make a controller that calls a data service layer that calls a repository data access object that calls an ORM that generate an sql query). Note, that  I’m not saying that the repository pattern is useless but we should ask the question if it is really needed (e.g if it is used only for data access and we don’t need change tracking we could use simple solution like Massive instead of NH or EF with all the added overhead). This leads as to the next point

2-Don’t follow blindly, always try to understand when to use a tool and more importantly when not to use it:

     Usually when a new tool* came out we found articles, blog posts and demos(usually with trivial examples that mislead the community of developers) showing how to use this tool and advantages of using this tool. But we notice that it is hard to find when not to use this tool (you should dig and have an objective critical mind). As I said earlier, we should use the right tool for the right job, in order to do that we should know when and when not to use it depending on the context.

3-Orchestrate altogether: how to use the right tool is good, combining all the tools together to get the right result is better and also harder. Sometimes the problem is not on the set of the tools or knowledge of how to use the tools but the challenge is how to combine them. This story from Udi Dahan (one of my favourite blogger)  illustrate what i meant.

4-Understand the context: in short use the right tool for the right job within the right context, some tools that applies in situation or project X doesn't mean that it is true in another situation or project Y even if it may seem similar. 

Another point, don't lie on assumptions specially for performance or concurrency problems. For example, you may use every optimization technique that you are aware of to reduce response time but the only way to be sure of that is by testing it and doing a stress test. (just because that is an optimization technique that worked for another project doesn't necessarily mean that it will optimize your current one at least you can't be 100% sure of it).

That is it for this post probably there is more but these are the main advices that i have in mind now and  that i think that are the most important to face the huge amount of  innovations on the IT world.

Read More

Applying design patterns to SOLID design. Keep an eye on KISS and YAGNI !!! Part 1

I will start writing a series of articles about S.O.L.I.D design and how to achieve it by using design patterns, I will not only focus on theory but I will give some examples and code to try to explain the problem that each principle of SOLID design is trying to solve and how to implement the solution using design patterns.

I have noticed that the problem with design patterns is not to understand them but most importantly when and how to use them in order to get a low coupled maintainable and reusable software. Many programmers (not only juniors) use design patterns just to use them because of the buzz words around them and because they have been told that it is a good practice to use them. But like any good practice if it is misused or/and misunderstood will cause problems instead of resolving them.

In case of misusing design patterns usually we end up with a more complex and over engineered solution, this conducts us to two other software design principles that we should be aware of, KISS and YAGNI.

YAGNI acronym for” You Are Not Gonna Need It”, usually applying the solid design principle and the use of design patterns means adding levels of abstractions and complex objects. Using the right pattern for the right job is important, otherwise we will end up with an over enginnered solution hard to understand and maintain with more lines of code and of course more bugs.

KISS: “Keep it simple stupid” always simple solutions are the best one don’t over complicate things by doing too much or an infinite loop of “what if”. 

That is enough for today i will develop more these principles and give some code examples in a later posts where i will show how to apply all these principles within a TDD process.

To be continued .... ;)

Read More