Services, practices & tools that should exist in any software development house, part 1
We could elaborate around the term ‘practice’ – what I am really eager to write though is about the minimum tools, services and practices that every developer should be aware of and every new manager or it software company owner/manager should install setup and maintain so that he/she can help his team(s).
Code repository/Versioning system
Eventually it is a central place where we have to save and share code. It manages aspects like version-ing and distribution through out the team. It is amazing but even today you may see around developers sharing code using shared folders, emails or setting up their own code repositories per project (waste of resources). These are practices that we should strongly discourage at all cost. There are some basic concerns around selecting a code versioning system.
(Type) Which one of them? Indeed we have quite a few, VSS, CVS, SVN, Git, Mercurial etc. In general, SVN and Git tend to trend in these recent years. Eventually you pick one depending on your existing know how and your requirements. In case you completely lack previous experience pick one that is trending (SVN or Git). In case you have your own personal preferences and you know what is good and bad you are free to make your choice and support it. SVN would be a good and safe choice at the moment (IMHO).
($$) Most of these services/servers are open source and free so you wont have to spent any extra money on downloading and installing them (SVN, CVS, GIt).
(Backup) After installing the service and using it, we should be aware that we need to setup a backup strategy and procedure, usually assigning this task to any of our administrators. So proper back-up and maintenance is required!
(People) No matter if we manage to buy or install the best code repository/versioning system in our company, if the majority of people do not follow, then it is another wast of resource. Bringing the tool inside the corporate context is the first step, the second one is to make the people start using it – this is where you gain all the benefits!
(Remote Access) A central code repository gives you the ability to enable remote working (if it is required or you are willing to do so). People may download parts of work code at home or at the clients premises and contribute hours – not being restricted to local corporate resources.
Issue & Bug Tracker
An issue tracker is a software service (usually a web application) that helps us create, monitor, manage and filter the different issues and bus found during development, operations or maintenance of a software solution. Any software product or service can be considered as a living organism, from the very early stages of its creation will need special attention producing errors or problems. Even when we manage to make it work when you release it in the production we always discover new problems, new issues or new ideas emerge.
In order to manage this long lasting process of finding, fixing, prioritizing and filtering all these issues and problems we usually fall back to the use of an issue and bug tracker – that can be access from all the related parties. In such a system we are engaging both developers, managers even the end customer to support the issue and problem life cycle of the end product.
The developers have a tool to associate problems with tasks of work, preserve a history of their fix work and probably able to reactively fix things as they show up. Managers are able to monitor the ‘health’ of the system by being aware at any time the maturity of the solution. That way they are capable to plan efficiently, give better estimates and provide efficent cost estimates for future releases and change requests. Last but not least the end customer is able to monitor the progress of work, get involved with the product at early stages and being able to log and push on the priority list things that he/she consider that require immediate attention.
I need to point that an issue tracker usually can be used as an efficient way of logging work hours – something that usually companies do using interfaces with other systems like SAP or siebel etc. Logging hours and creating weekly monthly reports you get valuable budgeting information regarding your teams / department (for free).
There is no system with zero bugs especially in it’s initial life and we can not log, archive, search and keep history of this evolution (through the fixes, issues or change requests) with no issue and bug tracker help.
There are some basic concerns around selecting an issue tracker:
(Type) Which one of them? We still have a variety of solutions. Their features more or less are the same in terms of what the system is doing. Each product though differentiates by providing a lot more on certain areas (eg. better reporting, better ui, price, compatibility and integration with other systems). My personal favorite and the one that I have seen in most companies is JIRA from Atlassian. I personally consider it as one stop shop and a great and decent product. I would also have a look on IDEA’s YouTrack which features great functionality in a cheaper price. Trac or bugzilla are interesting free open source alternatives.
($$) The situation is a bit mixed on this category. Great proprietary products and a list of free open source. It is really a matter of money I guess in this. I would strongly though recommend to invest on something good rather than use just for the sake of it a non usable or handy solution.
(Backup) After installing the service and using it, we should be aware that we need to setup a backup strategy and procedure, usually assigning this task to any of our administrators. So proper back-up and maintenance is required!
(People) As already elaborated – using an issue tracking service requires a change of work mentality on teams that have not seen this before. I think it is change that pays back very soon + the company is rapidly reducing man hours on its work log by automating procedures and tasks that were manual in the past.
(Remote Access) Remote access is a great asset, anyone (you want to) may have control & access to different parts of this service (per project, per company per client) and remotely can handle important work – regarding the end product.
Corporate – central Wiki
Creating software means exchanging information either related to the end product or the technologies used. The information flow within a software department or even within software development teams is a great problem even today. Problematic information flow at any level may lead to inconsistencies, problems or bad quality work for any team and product. We need to ensure that we have available those tools and practises that will enable all involved parties during software development to easily and flexible enough share information, document findings and share content together. We live in the era of blogs, twitter and web services. Tons of content is being logged, saved and archived through web applications. Google is indexing a searching web pages and related resources. So since we are doing it for our every day life, why not follow the same pattern within our company?
From my personal experience having a central wiki service available is enabling people to easily document and share knowledge either related to a specific project or something general far easier comparing to our old style of writing multi page and multi megabyte word documents. How many of you have received in your inbox huge word files with the title ‘System Specification version1’ having track changes enabled with thousand of comments and an ever changing structure. Word/Office documents in general are formats that aim to the printed outcome of the document and do not encourage viewing or working on the electronic format it self. I am not against word documents, but I am really against writting information, sharing information with other people and having to share the same instance of the same resource, merging changes or keeping track of them while I would just share a virtual page/ place on a wiki (like ablog) and start writting and sharing immediately.
I strongly engourage all of you to start experimenting moving your technical analysis or business analysis documents to such a service by transforming them to wiki pages and web resources. You will be amazed how easier would be for all the related parties (Analysts – Developers – Managers – The Customer) to find, read through efficiently and even comment of add information comparing to the old office sharing way! It is really a change and I always remember proposing such a thing to different management teams while getting back some weird eye – you are proposing something our of our comfort zone thing. But truth to be said – start capturing information in a wiki and stop misusing word or open office – produce word documents or pdfs only at the final stage.
(Type) ($$) Which one of them? Mainly most of them do the same thing. Plenty of choices. Proprietary solutions like Confluence are trending a lot but you can easily cover your needs with a free solution like MediaWiki etc.
(Backup) The same as above!
(People) As already elaborated – (yet again) – you need to persuade people understand the significance of information flow within an organization. Lots of people are used of the old way, messing around with excel and word documents. Eventually we have we have a solution for this uncomfortable way of working.
(Remote Access) Like blogs or any web resource wikis can be easily accessed shared (or limit them if you wish so) to a variety of people or groups.
Bear in mind that in some cases the combination of these services provides functions and automation levels that have not been covered in this blog post. For example, an issue tracker system may automatically associated issues/bugs with parts of the code as retrieved automatically by the versioning system. Or you may extend the design/solution or an explanation of a problem using a link to an issue that targets your wiki!
Build Server (Continuous Integration)
One of the simplest and accurate descriptions on the definition of continuous integration is given by Martin Fowler:
“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible”
Simple as that. A builder & integration server is a software service (usually a web application hosted on an app server) that will offer functionality like – automatic and regular builds of the code saved in the repository, run tests or other quality plugins and produce reports daily regarding the ‘health’ of the code. Team members will be able to monitor and get notifications about exceptional cases of errors in each aspect of the integration life cycle for example, build errors, number of tests failing after a specific update, quality metrics after analyzing the code. Wikipedia has a quite decent article on the subject.
There are some basic concerns around selecting a continuous integration /build server.
(Type-$$) Which one of them? We are lucky enough (yet again) to point that there is a variety of potential solutions both commercial and open source. When it comes to open source you will see services like Hudson / Jenkins / CruiseControl / Continuum. I have worked with most of them in different companies and I would say that all of them keep their promise on providing basic functionality. You will need to examine the different features / release and update cycles of the technology / and integration with other systems – in order to make your choice. When it comes to commercial packages there is a again a large set of available solutions- some of them would be TeamCity / Bamboo etc. You will find lots of blog posts around the net listing potential solutions for example this one.
(Backup) As already elaborated many times. After installing the service and using it, we should be aware that we need to setup a backup strategy and procedure, usually assigning this task to any of our administrators.
(People) An integration server is a component that works for the team, the main thing you want to ensure is that it works properly and that people around the software development life cycle pay attention to its work results (notifications, reports and monitoring facilities). Integrating continuous integration into your software development process you make a step towards being proactive on ensuring software quality. It is something that the management should evaluate carefully.
Testing (tools and practices)
Testing is one of the most important activities during software development. Eventually many people (even today) consider it as waste of resources and time. There are several things that we can do in order to easy our pain on these things + change our attitude towards this important (quality wise) activity.
Practice – Testing should be supported by the project management & upper layers. Testing does not start on the technical level when it comes to ‘actually doing it’. The testing phase starts when it is slowly being properly integrated in the project plan, in the attitude of the software development process, in the trust that the managers and PMs will put on it. There is no – magic button – called now we do testing – in a any software development team. I have seen the following mistakes through out my career.
- Project and task estimates do not include time (in a pragmatic manner) for proper testing either unit testing (done by developers mainly) or functional testing (done by a testing team – if there is one). By not assigning time, the developers are forced to tackle the implementation and testing of their tasks into the same time slot – resulting to skipping the less urgent sub task (the test). You can not easily persuade a project management or a budget manager of a software project to take into account testing as an activity. The results are obvious after the first releases or after the service/ product goes into production resulting to immediate switch from extreme programming to extreme testing on a problematic solution (something that is again completely wrong – see above the magic button effect).
- Developers get lazy: Eventually we can not blame the managers all the time. Software developers get lazy from times to times since they consider as well testing – as a second class citizen on their task list. Eventually this attitude should be enforced by senior management and by the overall software development practice followed on each department. For example when you introduce automated testing through the exeucution of tests on a continuous integration server – and you monitor the areas of the code where the developers have indeed performed test – you may apply the correct change of attitude to those not paying attention. Some times the complexity of the software and it’s design acts like a another reason of a developer moaning (I can not test) and this something that senior developers and architects should pay attention and modify as soon as possible potential parts of the code – make it modular and use the appropriate technologies in order to help/automate/ and encourage on the developer level the testing practice.
The tools – There several tools and practices that can be applied in order to implement and ease the work on testing. I will provide a short list on things I have seen in my java related career up until now.You may find many other links here for other programming languages or frameworks, here.
Developer frameworks and tools
- JUnit (Unit testing)
- TestNG (Unit testing)
- JMock (mocking techniques)
- Mockito
- Ejb3Unit (or standalone containers nowdays)
- XMLUnit
- HTMLUnit
Web testing /automating fuctional testing
Code Coverage – Up until now we have talked about basic steps towards integrating testing into our project management and every day coding. How we will be able to tell if we are on the right track? How good or how much are we testing? What about quality constraints applied by potential customers (example: we demand 80% of the business code to be covered by tests or similar requests). This is where code coverage as a practice kick in. It is tool to monitor and efficiently fine tune our testing activities. There are certain tools and frameworks that analyze our source and test source trees and provide metrics regarding the amount of real business being tested.
In the Java world you may see tools like:
Read along to the second part.
Reference: Services, practices and tools that should exist in any software development house / department – Part 1 and Part 2 from our JCG partner Paris Apostolopoulos at Papo’s log.
- This comes BEFORE your business logic!
- How many bugs do you have in your code?
- Using FindBugs to produce substantially less buggy code
- Introducing new technologies – How to battle resistance
- Java Tools: Source Code Optimization and Analysis
- Can we replace requirement specification with better understanding?
- Things Every Programmer Should Know
- Why Automated Tests Boost Your Development Speed
