Showing posts with label information systems. Show all posts
Showing posts with label information systems. Show all posts

Monday, 15 December 2014

Making good estimates and ways to reduce delivery dates



Making good estimates is very important because it keeps the project goals, dates and budget in a healthy state. Sometimes we take the easy path and just throw numbers for the budget and the time that it takes to deliver the project, but that's a bad practice, we must review documentation, experiences and the people involved in order to give a good estimate and support our numbers. The best way to obtain support data is through old projects and similar situations, this information should be easy to obtain if we keep track of what was the real budget and the real dates of delivery of all the projects.

First I will talk about the required steps to have good time estimates:

  • Divide the project in tasks. This is the first thing you need to do. Each task should take around two through five hours to complete, some tasks might take more time or less time, for example, certain tasks are very important and they need to be isolated, or it could also happen that they need to be completed all at once. Something else to take into account when dividing tasks, is to keep them as self independent as possible, meaning that there's no dependency on another tasks. It's always easy to estimate the time required for small items than the one required for big items, this can keep you focused and find additional requirements/documentation/people that you will need to complete each task. This also helps when you're looking for similar situations in the past, it's easier to find a matching similar situation when tasks are divided properly. Another good thing about this is that it helps in understanding if some tasks should be made by another team, for example, in some cases, testing accounts can be provided by another department because they know better what are the things that they want to test.
  • Review old projects and find similar situations. This is the best way to know how much will it take to create a similar project. Take into account that if the new project is really similar, we may end up finishing it sooner than expected. This is because in most projects, there's a learning curve for items that needs discovery and reading documentation.
  • Poker game. When deciding the amount of time required for a task, it's a good idea to have the opinion of one or two experimented members of the team, they always see something that is missing for the other individuals, and that could be key to set the estimate for the task. Keep in mind that if the estimates provided are very different, is a smell of insufficient data to set the required time for completing a task.
  • Pre-steps, Post-steps. It's important to know if there are another things needed to start and to finish the task and add it to the estimate. For example, you might need to create a branch for working on the task, set up a new account for a system, wait for a testing environment, etc. Those are the pre-steps, but when you finish the action items of the task, there might also be another post-steps, like creating release notes, sending out an email to the business owners, deleting testing accounts, etc.
  • External factors. Network team is too busy to set up a testing environment? Working with the financial area in a time that they cannot provide information fast? Can you release the software project in the date you selected?. This and many other questions are important when creating an estimate and deciding on dates of delivery, if you have been in a similar situation before, it could be easy to know when some external factor will be affecting the date of delivery.

There are many things to take into consideration! but something to keep in mind is that you should stay as "optimistic" as possible, meaning that you cannot put as a support to your estimate, the fact that there could be an "Armageddon" tomorrow, and your project might not be completed on time.

There will be situations that can delay the delivery date of the project, but they should be addressed at the moment that they happen, and the project should be reorganized accordingly. Another thing that I would like to talk about is ways to deliver the project in less time, and with less effort:

  • Get all the team interested in the project involved. Software projects are not completely developed by the software team. If there are going to be changes to the some department systems, it's a good idea to have them involved as much as possible, and even assign some tasks to them (like finding testing accounts, providing data analysis, etc). The outcome of this will be early checking the requirements of the departments and based on that, planning the next steps, on the other hand, the departments can know how's the project going, what are the expectations, provide early feedback about features, and give relevant data for testing.
  • Buying systems. Many projects are similar to current systems in the market. If you can buy a system that has a decent trade-off between cost/value/quality, think about buying it and customizing according to your needs. You should buy a very known system in order to trust that it has been deeply tested and that can reduce the time required for delivery.
  • Request help from another company. If you have the budget, it can be useful to have another company help you, specially if they're experts on the system you want to develop, this can be cheaper than expected, because they have passed the learning curve and can save you a lot of time, and allow you to focus on another projects that can only be developed by your team.
That's it for now. I hope you enjoyed this entry. Let me know if you have any questions or if you would like me to talk about another topic. Many thanks readers!


Sunday, 26 October 2014

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.

Tuesday, 16 September 2014

Front end Performance - An overview of major software aspects

In this post I'll be writing about Front end performance focusing on web applications, but many things apply to desktop and mobile systems. You'll need some background on web development to understand the story behind the scenes, I also recommend reading the introduction post of the series to know all the topics of this series and the focus I'm having. The purpose of this post is to understand the importance of front end performance and things that you can do to keep it fast.

Let's start with a list of things that matter when developing web applications, then I will give you some tools that will help you in having things in order:

  • CDN For static elements. Using a Content Delivery Network for static content like images, javascript, files, etc, helps in maintaining a low bandwidth usage and it's a must when you've a web site with a lot of traffic because this content is usually the bigger part of your web page, and if you have a lot of visits, you'll probably have trouble in serving all the requests from your hosting server. You can analyse this by downloading your web page and see how much space does this type of content represents in comparison with dynamic content.
  • Image optimization. If you have a web site that uses a lot of images, let's say that they represent 80% of the weight of your site, and if we take into consideration that not optimized images can weight more than 3x the size of their optimized version, if you have a web site using unoptimized images can result in a web site 240% heavier (80% x 3 = 240%). What this will mean is that your web site is going to be slow, it will take at least... yeah, you got that right, 240% more time in loading than what it should be.
  • Data cache. Most web servers nowadays have a cache system for pages. This works by setting up pages and their expire time. This can help in slowing the resources needed to load your web site, this also helps with the page speed.
  • Optimizing CSS, Javascript, HTML. This is a big topic, I will dedicate an entry for it, but what I can say now, is that it really matters when you want to have a fast web site and it's also easier for the search engines to index your web page.
  • Friendly URLs. This means to have urls that when you read them, you can tell the story in that page. for example, it's much easier to read: www.maps.com/Mexico, than to read: www.maps.com/default.html?Country=Mexico.  And guess what? for search engines it's easier to index, because the first thing they use to categorize the page is the url. This can also help when using google analytics, I will dedicate one post to this, but in summary, with friendly urls you're able to have a better understanding of what pages are being visited, and this can give insight on what you should be working and improving.
  • SEO. Another big topic, I will create a separate entry for it. It's important because if you have good meta tags, meta keywords, friendly urls, and the HTML as it should be, then your web site is going to be "friendly" for the search engines and more people will reach it when searching for related topics. There are many, many things related to SEO, for example: is your web site for a particular Country? Are you hiding it for some others? are you using the right domain (.us, .com. org) ?
  • User friendly interface. A web site must be easy to use, you should be able to understand the content easily and the navigation needs to be friendly, this will help people and will make them return to your web site.
  • Optimized for mobile. If you've a web site targeting mobiles, you'll need to have an optimized version for it. Usually with lightweight content, and the interface with some adaptations to make it easy to navigate.

Now, let's talk about some tools that can help us to keep things in order:

And what could happen if you don't care about this concerns? Our example is going to answer that question:

Example: unoptimized web site and hosting prices

  • Let's suppose that we've a web site in which most web pages weight 6mb. 
  • The web doesn't require a lot of processor speed, because most content is static.
  • Let's imagine that we've been investing a lot in marketing and that our page is reaching 100,000 visits per day.
  • How much bandwidth do we need per month? We will need: 30 * 6 * 100,000 = 18,000,000 mb each month.

Now, I will calculate the cost of not having an optimized web site. For keeping things simple, I will use approximate values. The prices are based on a true hosting vendor: each month your hosting plan includes 5 TB of bandwidth, we're using 17.5 TB, that means that we're exceeding our consumption by: 12.5TB. The price for each extra TB is: $42 US, this means that you'll be paying: 12.5 * 42 = 525 extra dollars each month. That's a lot! That could be used for campaigns, or for other stuff. And you'll probably have more visitors if you have an optimized web site, and something I must also say is that optimizing bandwidth usage is not complicated, so there's no real reason for paying that extra dollars.

Ok guys! that's it for now,  hope you're enjoying the series. Let me know if you want me to talk about a topic in the upcoming entries :)