Things every programmer should know

Learning process of developers never ends. It is in our DNA to continuously feel the need to learn and self develop. As much as we learn, we have even more to learn. The technology world is moving so fast that to keep the pace and be up to date with cutting edge knowledge, we need to embrace learning as part of our daily activities. Whenever we say we learned to use a framework, we see that 7 other frameworks have become famous and we need to take a look on them. One of the most frequent questions of my students is the question “what should I learn to be a good programmer?”.

Luckily, nowadays, learning resources are so vast, we have difficulties to chose which one to pay attention first. We have plenty of books available (free and paid), free magazines, blogs, video tutorials, MOOC courses, etc. However, cutting the line what one should learn to be a good developer is not an easy task. As doctors have chosen to specialize only on one part of the body, developers too need to decide for a specialization, be it system developer, web developer, business application developer, etc. The specialization is something which comes to question when you reach a steady state of development knowledge and experience, but what do you need to learn to get there. What could be a good developer knowledge path?

Over the time, I have come to conclusion that developers need to know the whole stack of code execution in order to succeed.

What do I mean with this? The computer literacy starts with using the computer and perhaps some basic configuration and application usage knowledge. If you advance in configuration skills, you learn perhaps also about servers, monitoring, user management, etc., you start learning system administration. Then you need to network the computers and servers to work together, and start learning networking, which builds on top of administration skills. Then you feel the need of automation, and that’s where you start with learning programming.

Why do I think this model works? In early times of software development, we used to have only desktop applications which performed certain functions. Today the whole view is different. We rarely develop single computer applications. We either create a web application or have a network aware app. Those applications often may face problems of different nature, especially if they are running inside a corporate infrastructure where proxies, firewalls, and other infrastructure components interfere with the traffic and environment. Most of the time, problems caused by those components will not demonstrate themselves very clearly and often it will look like the application is failing. Finding the root cause of the problem requires good troubleshooting skills and that requires understanding of system administration and networking which are the layers above which your code runs. If you fail to have the understanding of underlying platform, you will be left alone to find what is the problem with your code, as most of the time, system administrators/network administrators will not be able to identify why your application is failing (and perhaps it is not their fault as they do not know the ins and outs of your application), therefore the judgement will be that the code is faulty 🙂

What should you focus to learn? Do you need to be a system administrator and network administrator before you start to learn programming? No, I am not saying that. My suggestion is you get at least the basic understanding of operating systems (perhaps not all of them but those which are in your environment), learn how user management is working, the privileges, and the connection to central user management like Active Directory. Learn how to read system logs, that is the place you will most often find valuable information about what is happening with your code and find the clues about what is going wrong, how to list running processes and see who is consuming the memory and who is consuming the processor. Learn a little bit also about system security,  to setup and configure your production environment and its subtleties and the basics of how the computer networks operate. In the long run, you shall benefit from this knowledge for sure.

I do believe that a “complete developer” is not the one who only knows to write code and nothing else. You should know the whole picture of the environment you develop and the environment your code runs, and this requires you to get a little bit out of your zone and see what you have around. I would like to explicitly clarify one point here. I do not think that developers are above or more valuable than System Administrators or Network Administrators. Everybody in this ecosystem has his/her importance and value. I just want to point out that if you want to know the full stack of execution of your code, you have to have a clue what happens beneath and these are the things every programmer should know. Troubleshooting problems of your applications will most likely come to you as the last line of support, and finding faults in system or network requires basic understanding how those function.

What do you do when your code has cancer?

One truth about business software applications is that they evolve together with business requirements. From different reasons, sometimes from lack of experience of developers and sometimes from not having enough time to devise good solutions, the code often tends to create some sort of cancer inside, which progressively grows to unmanageable pieces of software until it breaks the whole system.

What do we do if we find such phenomenon in your code?

In my experience I have seen that dealing with such code is almost inevitable in brown field projects. Ignoring them makes things only worse. You have to face it and treat it as it is a disease which needs to be cured. Whenever I face such a situation, I follow these steps:

1. Isolate

Changing the code without breaking the whole system, or refactoring as is called in software development terminology, is not an easy task. Every change must be validated and tested well to ensure that changes do not break or alter the current functionality. In order to stop the bad code growing, we need to isolate it first. Isolation could be done by aiming abstraction through loose coupling the part which needs to be isolated. The abstraction is done by creating interfaces for every class that needs to be isolated and make dependent classes call to interfaces instead of real classes. This may require introduction of inversion of control (IoC) / Dependency Injection (DI) container. Each isolated part must be supported by quality unit tests which ensure that the abstraction maintains the code logic which was in place. Unit tests will also help us in the second phase.

2. Repair

This phase is quite simple. When you arrive here you have isolated the bad code and protect the functionality with unit tests. Now you can safely start to refactor and change the bad code. As you change, you should continuously run the unit tests to check if changes have any unexpected effects. If the unit test coverage is OK and they are written well, then you can safely proceed as unit tests will spot if you have broken something unintentionally. I would highly recommend Test Driven Development in this phase.

3. Integrate

Integrating the isolated code is the last phase, and most probably the easiest. Now the bad code should be gone and the functionality is unchanged. Often you shall find this phase unnecessary as the integration has been done during the phase 2. However, sometimes you will find some kind of double abstractions resulting from a lot of refactorings and you will see the opportunity of cutting these unnecessary code.

Conclusions

Perhaps this strategy looks very simple, but in my experience, it has been a very effective one. We are not always lucky to land in green field projects and define good code from the beginning. Besides, it is not always easy to maintain the code in good shape when the team has many developers and there is not a good development process in place.  Sometimes you deliberately allow the code to go in bad direction as a compromise to speed or resources.

The most important skill for Software Architects

I trust anyone reading this post title most probably is expecting to see something like UML Design, OOP Design, writing code, etc. I would not consider these in required skills list, these are I would say, mandatory skills for a Software Architect. In my opinion, the most important skills for Software Architects are the communication skills.

The importance of communication skills

In Microsoft .NET – Architecting Applications for the Enterprise (2nd Edition) book, the role of the software architect is defined as a person who ties together the requirements and specifications, and one of the most important responsibilities of the software architect is mentioned to be the acknowledgment of requirements.

This requires a lot of communication with people of different profiles and various knowledge of technical jargon (project managers, business analysts, potential users, etc.), and it is a natural expectation that Software Architect should speak the language of business rather than the other way around.

Speaking the language of business is one part of the communication. Next comes communicating that business knowledge and requirements to development team. In my experience, I have seen several situations that developers and business people were speaking about the very same solution, but the language terminology they used made everybody think that they are speaking about two different solutions.

It is the technical skills of planning, designing, development, and implementation of a software solution that qualifies one for  the position of Software Architect, but in my opinion it is the soft skill of communication that is the most important skill for software architects and the skill that makes one an appropriate choice to be in that middle point of the team. As my boss says, we must talk talk talk.

What can you do to improve your communication skills?

Of course there is no silver bullet to this problem. We humans tend to be unique in our behavior and skills, and as such the recommendations can not easily be generalized. However, I have three points which I can recommend to anyone:

  1. Seek for sincere advice from people around you, be it your family, your friends, or your colleagues. Generally, it is not easy to get someone to sincerely tell you what they think. People sometimes don’t like to tell what they think and sometimes they are afraid of being percepted as criticizing others, so they don’t tell you exactly how you are being percepted unless they get this freedom from you. Try to make people feel comfortable saying what they think about your communication skills and appreciate sincerely their comments.
  2. Spend some time with yourself thinking about your communication with others. What did you say, what was your intention to communicate and how was it percepted? This could be very helpful to find your weak points, on which you should focus to improve.
  3. Read the book How to win friends and influence people by Dale Carnegie. This is one of the best books I have read and I can confidently recommend this book to anyone. It has an immense set of advices which are very useful for improving one’s communication skills.

You can find plenty of advice from different resources on internet, from books, and from people around you about how to improve your communication skills. Pay attention to the input you get especially from people, you will appreciate it at the end.

Web services vs. SOA and pretty URL vs. REST

It has been quite a time since Service Oriented Architecture (SOA) and Representational State Transfer (REST) architectures are around, yet there are some misconceptions about them I hear very often, which I would like to discuss here.

1. Having web services does not mean you have an SOA architecture

This is perhaps one of the biggest misconceptions about SOA architecture I hear very very often. I see many developers thinking that if they have a web service or two in their architecture, they say their architecture is an SOA architecture. I think this comes because of two reasons: 1) “Web service” and “service oriented” resemblance in naming makes people think they are the same thing; 2) As web services are the most common way of implementing an SOA architecture, this pushes people think that when they have created one web service, their architecture is an SOA architecture.

An SOA architecture is characterized of composition of independent services which encapsulate business functionality and expose it as a service, which can be  a web service, a windows service,  or any other form of exposure. Ubiquity of web and advancement of web development technologies which made the creation of web services easier have put web services as a mean of choice for implementation of an SOA architecture, however, the definition of a service within an SOA architecture does not put web services in any special position regarding implementation of SOA architectures. Here is the definition of a service from Open Group:

A service:

Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)
Is self-contained
May be composed of other services
Is a “black box” to consumers of the service

 Web services and SOA make a great pair which power a lot of important and popular service out there, but it should be crystal clear to Software Architects, Developers, and anyone contributing to software developments that having web services does not mean you have an SOA architecture.

2. Having pretty URLs does not mean you have a REST architectural style

REST architectural style is another popular topic lately, and as such, is subject to a lot of misconceptions as well. REST has brought simplicity to implementation of web services and is embraced very popularly from the web development community. It plays well with the HTTP protocol, which we are familiar with ever since the beginning of www era.

One characteristic of REST architectural style is that resources are at the center of the architecture, and they are beautifully represented in URLs. REST has brought us pretty URLs, and therefore people have created a connection between the URLs and REST architecture. Leonard Richardson has developed a maturity model which tells the level of your API or RESTful services to what degree are RESTful. Martin Fowler has a great post about richardson maturity model. The levels are described as in this picture:

richardson's rest levels of maturity for REST

The very first level of the pyramid, level 1 is the implementation of URI or introduction of resources and at this level of implementation resides using the “pretty” URLs to connect URIs to resources. The level 2 refers to using HTTP verbs and the most advanced level, level 3 refers to using hypermedia or following HATEOAS.

In Richardson’s model is clearly seen that pretty URLs are the very basic level of implementing RESTful web services towards a REST architecture and clearly explain that having pretty URLs to access your services does not mean you have a REST architectural style in place.

In my opinion, implementing an SOA architecture and RESTful web services requires to have a clear understanding of these concepts, the constraints which come with them, and what is required to have such an architecture in place. Clear understanding will lead to effective architectures which allow us to reach the promises and benefits of these architectural styles.

Architecture of web applications

I consider software development more art than exact science, and as such, in software development almost always there is not a single way of solving a problem. Although there are defined best practices, it is a matter of problem being solved and the knowledge of the team that influences most the definition of the architecture of web applications and software applications in general.

Recent years has brought to popularity using REST in the architecture of web application solutions. I am a huge fan of REST, I like it a lot mostly because of its consistent way of expressing CRUD operations and brings simplicity to the API implementation. The use of REST has been pushed further with advancement of MV* JavaScript frameworks as they tend to have a natural way of consuming resources from REST APIs.

Lately, I am seeing that most newly built web applications tend to use REST in some way, if not exposing APIs, they do consume one or more of them. In my opinion, REST tends to create a viral effect on developers, as much as you use it, you want more of it. Now after we experience REST, I think there is a question which pops up:

Do we have to expose everything as REST API?

The universal answer “it depends” applies here very well! If you want to use a client side framework such as AngularJS that does not need server-side code and is well suitable to consume REST services, it might be a very good idea to expose the whole business logic as REST API and consume it through AngularJS services. This comes with additional benefit that if you want to have a mobile app of your web application, you do not have to write any additional code on server-side to support your mobile app, just consume the very same REST services and you are good to go. A diagram representation of such layered architecture of web applications could look like this:

Web application architecture with REST API and client side MV*

This is one of the most often used architecture styles I am seeing these days in web applications. However, what if you are not keen to using MV* JavaScript frameworks and want to use a server-side backend and generate your HTML representation using let’s say ASP.NET MVC. Do you still need to expose business logic as REST API?

Exposing business logic as REST API or any other form of service layer, if you do not have multiple types of consumers (web, devices, etc.), in my opinion is waste of resources (time and effort). Exposing and consuming services do introduce a level of complexity (you need to put extra effort on error handling, security, versioning, asynchronous access, etc.)  to the architecture and application code. This complexity is non considerable if you have multiple consumers of your application as it avoids writing multiple times the same functionality, however, if there is only one consumer and it is the web GUI, then in my experience I have seen that it only makes things worse. In such a situation, going with an old style server-side backend is a lot more easier. If you say I have a mobile client as well which consumes part of the functionality, in that case I think it is better to create a small REST API service group exposing only that part of the functionality, is a better choice. This will also allow you to develop your web app and mobile app in different paces (if you have lack of developer resources, you shall come to this requirement). The modified version of our new architecture will look like this:

Web application architecture with server-side backend and rest api

Sometimes we are keen to jump to new technologies and architecture styles just because its presentation looks attractive and we like to get our hands in it and give it a try. Often this pushes us to situations which makes maintenance of our code base difficult in later stages of our application lifespan. It is very important that evaluation of the application architecture to be done as early as possible and be judged from the simplicity and maintainability perspective.

 

Staying up to date with technology developments

For a software developer, staying up to date with technology developments and follow latest trends of software development is of utmost importance. But nowadays, the number of online posts/activities that are competing for our attention has increased exponentially. Dealing with all this load of information and staying up to date is not an easy thing. I have create a simple strategy which works for myself and I’d like to share it with you.

 

Conferences to follow/attend

Conferences are where the latest developments usually are formally announced and demonstrated. Attending developer conferences gives me the opportunity to listen to the demos and presentations of latest trends in software development as well as network with my peers. Sometimes, attending conferences is costly, especially if you target one of the major conferences, but luckily, most of those conferences publish their videos online so we can view them.

Some of the major conferences I follow are:

User groups

Local users groups provide excellent opportunities to see what your peers are up to, what is happening on the market, and what technologies and trends are actual in your neighborhood. There is also a value added activity of networking with your peers which is a good benefit. There is a user group for almost anything out there so just search for user groups at your neighborhood and join them.

Sites to follow

There are some major sites where I follow latest developments on software development technologies and practices, and entrepreneurship (in my opinion, developers should be quite familiar with what is happening on the business world as well) . Of course the list of the sites will be relative to your interests and platforms you use, but here is my list:

Persons to follow

Every industry has its own influencers who evangelize technologies and practices, and sometimes these people define the trends the industry follows. It is very important to chose who you follow as in some ways, by following a person you accept his influence to some degree and if this person is a successful one, you will benefit positively from his experience and thoughts.

Here is a part of the list of persons I follow:

Conculsions

It is quite challenging to stay up to date in this dynamic world, and we need a process in order to excel. Having a defined and structure workflow of flowing the information in and getting most of it will be a skill we all have to master. Depending on the technologies you use, the market you work in, or your interests, most probably your list will not be same as mine, but the principle behind is valid for any interest I think. It is important to define your standard sources of information and supplement them with additional sources from time to time or even substitute your standard sources with new ones after some time.

What are your sources of information?