Soft skills - An overview of major software aspects

The "darkest" required aspect of sofware development! (or at least I believe so). But in the end it is a very important aspect -just like the others- because it relates to communication, and the ability to obtain the required information at the right time.


These are some important soft skills for software development:

• Communication abilities. Needless to say how important it is! developers must find a way to effectively communicate with the team and vice versa. Something I always suggest, is to write what we want to communicate, it is usually easier, and then start a discussion with the team.  Communication abilities, include the effective way to answer emails, which can led to a complete entry, but the thing is to always focus on the key questions of the email, and answer then, once that that happens, then you can continue with less important topics like "personal" questions. For example, let's suppose that you arrive late one day and you receive an email asking about why a component is not working properly and the reason for you to be late. You should start answering the reason why the component is not working properly, and then at the very end of the email, the reason for you to be late at the job.
• Team work. You'll usually find yourself working in conjunction with other members of your team, so it's important to know how to be a good team player. Be polite, be respectful, keep focus on what you're doing, be assertive, be on time, and be inspirational to the other members. Put your personal feelings on one side and be professional, try to understand your team-mates. Some concrete advise for example, is to be very communicative, for example, if you're taking a day off, you're probably telling your boss about this, but you should also tell this to the members you're working on, so they can get organized. Take an active part when you're being asked about code conventions -or any  convention: arriving late, taking day offs, changing lunch time, etc-. That is the only way to keep a team happy and effective.
• Negotiation. When you're in charge of a piece of the system, sometimes you can be asked to do stuff that is very complicated and that cannot be delivered on time. In this cases, you must communicate this, and id possible, analyse what you are being asked to do, and come up with another option. This apply usually to developers, but also for project managers, when they're being asked to include a lot of features, they should find a way to balance the due dates vs the work that has been developed.
• Education. Unfortunately -or fortunately?- education has a lot to do with soft skills. Usually your parents are the first ones to teach you how to handle situations. Of course, having a "bad" education is not the end of your career, you must also read books related to this topics to get a full understanding on how to be an excellent developer. And another thing to keep in mind is to use common sense. If you're in a complicated situation, what can you do to improve it? is it your fault? what options do we have? And keep yourself positive, don't let other people bitterness change the person you are. Think always on a polite way to handle situations, if you receive a rude email or someone is acting awfully, you shouldn't do the same, keep focus on the goal of the project and find a polite answer to the request they're making.
• Ownership of your tasks. You should always take full responsibility of your tasks, this means that you should find a way to get all the things you need to complete the task. A good example is scaling communication ways. If you're in need of some information, and you send an email, if you're not receiving an answer in a reasonable time, you should then try chatting, if that doesn't work, then try calling, and finally, if that also doesn't works, you should talk directly your request. This is why daily scrum meetings are important. If you get stuck on something, you'll find a way by letting everybody knows about your need. There are many other things like, checking your own progress, and see if you're not going to deliver on time, make everybody knows the reason. Don't forget to do on-line research whenever is needed and try to find interesting ways to solve the problem.

These are some consequences when the team doesn't have soft skills:

• Critical errors because of a bad communication of issues
• Loosing a lot of time in questions that were not addressed at the right time
• Big differences between: what is really needed, what it's being done, the project specification and what the customer requests

This are questions that can save a project:

• Do we really, really need all the features for the first release?
• Is there an existing software that can help us in developing the project?
• Is everybody in agreement with the project specification
• Is it possible to divide in more releases the project?

And that's it folks, this series is coming to an end! I hope you enjoyed it. Let me know if you have questions or if you want me to talk about something in particular for future entries.

Administrative goodies - An overview of major software aspects

I wanted to dedicate an entry to the administrative aspect of sofware projects, because sometimes the project can have a very good architecture, excellent code and marvellous performance and yet it fails the expectations because it has a very poor administration. I will not get very deep into this topic, because it is the least technical aspect (at least for developers and IT persons).

Basically these are the major administrative aspects:

• Licensing. How are you going to license the project? is it a free social project? are you going to sell add ons? how much will each license cost. These are some questions that must be answered when creating a software project, because in the end you need to find a way to pay for the development of the project. You must also make sure that you're following the rules of your country, otherwise you'll have problems when trying to commercialize the project.
• Marketing. You have to know very well your target market to do marketing. It's important to reach your people and to make them use your software. Here you must think about stuff like: is there any other similar software? how can I reach more people? what are the strengths of the system? How can I communicate the features of the system to the target users?
• Brand creation. It doesn't matter if the project is going to be free. if you're targeting a wide market of people, you must create your brand and make everybody recognize the project with the logo or slogan of it. Think about a small and easy to understand slogan that describes your system. Have you seen this before? of course! for giving you an example, all apple products have a very small slogan that makes all the world know why are they created and the usage that each product has.
• Payment methods. If you're going to commercialize your project, keep in mind the payment methods, and analyse the options that you can offer to your target market.
• Contracts. If you're selling the software to another company,  don't forget to have a very good and specific contract! The documentation made for the test can be helpful, because it describes the features covered and the expectations, so you can use it for the contract with your customer.

Short entry, I know! but I hope you like it. Leave comments at the end of the section and let me know if you want me to talk about a particular topic.

Clean code - An overview of major software aspects

Let's start by defining what's clean code?. This definition can get very particular and specific depending on the language you're using for developing and the assumptions of the system. But basically, I would say that clean code is code that is easy to understand and easy to use for the environment that it was created for. Just like Robert C. Martin stated in his book:  Clean Code: A Handbook of Agile Software Craftsmanship: , “Clean code is code that has been taken care of. Someone has taken the time to keep it simple and orderly. They have paid appropriate attention to details. They have cared.”

Sound pretty straight forward isn't ? But truth is that it takes time and effort to have clean code, and another important thing to notice, is that code is really the core of any system, and that it almost always is reused by other developers, so it's important to keep it clean, besides, having bad code lead to terrible outcomes that will be explained later. Extending a little the defition, this is what I mean with code easy to understand:

• Relationships between projects are easy to understand
• The methods are easy to understand and they don't need a lot of additional comments more than their name and the context to  make sense of the usage
• The flow of the system is easy to understand and you can guess it by reading the code
• The names of the variables make sense and it can give you context of where they belong and their usage  

On the other hand, this is what it means to have a code that is easy to use:

• Classes and methods are small and they're in charge of only one thing
• There are API for projects and that's the only way to communicate between other sub-systems
• Testing is easy and there are interfaces for important classes
• At least 80% of the code has unit tests, and there are integration tests for all the features
• There is no need to have a big set of documentation for the project. The methods, classes and structure of the projects, make it easy to understand

Something to really keep in mind are names of the classes and methods. They are very important because business people also talk about them, so you are very likely to have smart conversations using names of variables / classes / projects. Besides, new developers might be re factoring or adding new features to the code, and they will have a big "?" on their minds if the names are "encoded" in a weird language. You don't want to look like him, right? 

The cost of not taking care of the code is really high. We're talking about:

• Productivity
• Efficiency
• Assertiveness 

You cannot have a good estimate of time for new features when you're working on a system that has bade code. You will never know how many new bugs you can create when you're adding features or how the flow of the system is affected as well as how many areas you need to do regression testing.

Another entry comes to an end. I hope you're enjoying the series, let me know if you want me to talk about some particular subject on software development, I will be happy to do so. By the way, I really recommend to read Robert C. Martin book:   Clean Code: A Handbook of Agile Software Craftsmanship . I'm sure that it will help you in creating better code.

  

Software application architecture - An overview of major software aspects

Software application architecture (I will deliberately use architecture from now on)  is an aspect that should involve the whole team, from the business owners to the developers and the final users -at least a prototype of them-. I will use the MSDN definition because I find it complete and easy to understand: Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

Now that we know it's definition and the usage it has, let's talk about key factors related to architecture:

• Communication. I'm not just talking about "being available" for answering questions, the business owners must communicate new features required as well as bugs found in the business logic. They must provide detailed and specific descriptions of the process that the developers are going to work. This also apply from the developer to the business side, if the developers find a feature very hard to develop, they must suggest something and make it clear to the business owners, doing so may provide a different way to tackle the problem
• Documentation. The software system must be documented and described in detail. This documents are the contract that will prevent misunderstands and will help new members of the team understand the system.
• Keeping a list of concerns, assumptions and expectations. This can help when reviewing the project in the future and understanding the architecture decisions. It's a good idea to keep it organized by subject. For example, divide it in infrastructure considerations, software concerns, business analysis, etc.
• Create more than one architecture. It would be very hard to have one architecture, ideally you will create more than one with enough detail to start testing and see how things are looking. It's better to do it iteratively and in an incremental way to refine the architecture.
• Have a due date for completing the architecture. Because architecture involves the whole team, it could take forever to have a "perfect" and approved architecture, but the reality is that we will need to make adaptations because we cannot know everything up front, but we can create an architecture that is ready to handle future changes. So it's a good idea to decide on how much time is the team taking for defining architecture, and start working right away to find issues in an early stage of the project and address them as soon as possible. 
• Take an active part in the decision making and then follow through!. It would be very important that everybody gets involved according to their role in the project. Once that the decisions are made, they should be followed. For example, if you need a web service for some sort of operation and the team decided that X web service is the right one, then it should be used whenever that operation is required. Also if the architecture requires to do some code files in order to create a process, they should be created whenever a new process is requested. On the administrative side, there is also an effect, if the team decided to use an excel spreadsheet for uploading information, the business side must accept this responsibility and create the required files.
• Hide details of implementation. When you're working with a software system, it is important to have a good service layer to reveal only what is necessary. Revealing architecture to other systems can be dangerous for security and in the "best case" it can make other developers think a lot on things like: "why have they do that?". Well... that's not the concern of people connecting to your system, they should only know how to obtain exposed data required for other systems.  

Important factors affected by the architecture:

• Time for adding features. If we got a good architecture, then the new features are pretty much "expected" and they can be delivered on time. This is because we would probably leave the "skeleton" ready for the upcoming features of the system. Besides, when you have a bad architecture, it's really hard to obtain time for re factoring,because it's the most technical aspect of software development, so the other areas involved will not clearly understand the importance of the architecture, so they will not allow much time for re factors.
• Performance of the system. If we do the right choices, the performance will be the expected. This is related to the entries of performance: Back end and Front end.
• New people in the team. If there are new business owners or new developers, a good architecture will make the learning path very straight forward, and this will save time and money to the company.
• Integration with other systems. Most systems nowadays interact with other systems. Having a good architecture (for example, creating a web service layer) will make it easier to interact with other systems, and it's important to see this on the beginning of the project. Doing so will save a lot of time, when this kind of interaction is needed.
• Bugs. Good architecture leads to less bugs, bad architecture leads to a lot of bugs. That's something easy to understand, because if the architecture is not ready to show good messages whenever you're having a new issue, it's very unlikely that you'll find the reason of the bug, also if the architecture has bar practices like not having a good structure of the project and then creating a lot of methods for the same thing, you'll probably find the same bug repeated in different areas of the system.
• Value. The architecture plays a very important role in the value of the project. In the end, the expected times for adding features, the performance, the usability, the results and everything related to the system is directly derived from the architecture decisions, and the users will take advantage of the system, if and only if our decisions are appropriate.

It's complicated to give and estimate on how the architecture affects software systems, it depends on a lot of factors and the context of the systems, but I will use a piece of an interesting article to give you an idea:

"It can be hard to measure the cost of software erosion and convey this cost to non-technical people who often have to sanction work to stop software erosion. Even though software erosion causes reduced productivity, reduced quality and increased time-to-market, no one specific point of erosion causes these effects in isolation, rather it is the effect of multiple points of erosion that combine and reinforce each other to cause them.

However, a study by the US Air Force Software Technology Support Centre (STSC) attempted to put some rough measure on the costs of software erosion. The researchers took two versions of a mature software system (50k LOC) and asked two different teams to perform the same maintenance task (adding approx. 3k of code) on their respective version. Version 1 was an existing system suffering software erosion. Version 2 was the same system but with the architecture restructured to remove erosion.

The results were staggeringly different. Team 1, working on Version 1, needed over twice as long as team 2 to complete this relatively short task. Furthermore, Team 1’s results contained more than eight times the number of errors than the work submitted by team 2, working on version2. Erosion in a small system such as this still had the potential to lead to significant problems when the software was maintained."

This is the link to the original article:

http://www.methodsandtools.com/archive/archive.php?id=85

Ok, this is just the tip of the iceberg, but I wanted to share with you, how important is to have a good architecture. My best advice is to do early planning and to have great communication channels between teams, this are the very key factors to success. I hope you're enjoying the series! if you want me to talk about a particular software topic, let me know in the comments.