Analysis Of A Software Developer
- Details
- Created on 14 October 2014
- Written by Steve Burrows
Read the job advertisements in the newspaper or employment agency websites and you’ll see adverts for “software developer”, or sometimes “computer programmer”. So what is one? The simplistic view is someone who creates software programs, and in the case of a small business which has only one or a few developers that probably holds true - but it fails to communicate what a developer must be in order to create good software, which in turn leads to poorly specified job adverts and unsatisfactory appointments.
Looking at the software development structure in larger organisations with substantial teams of developers helps to understand software development whether one is seeking to appoint a specialist or an all rounder whose skills must encompass all roles, so here are the basics. Somehow each of the following roles must be performed when developing software, whether by a team or a polymath, and understanding them leads to better hiring.
Analyst: this is the person who discovers (and documents) how a system or process - a method of doing something - works, and why; so that it can be assisted or replicated by software. The analyst’s product is typically a specification of requirements - things the software should achieve, and high-level design - how it should behave.
Architect: the architect determines the building blocks of a system, the components that will be used in its construction and how they will interact. Commonly the architect is also responsible for ensuring that the components needed for a new system will interact with existing components and ensuring that where possible existing components are re-used instead of buying or building new ones, thereby avoiding compatibility problems, wasted expenditure, and excessive maintenance. Components will include hardware, software, networking etc. - all the parts of a complex computer system.
Software Designer: the designer takes the requirements and high-level design generated by the analyst, and the constraints imposed by the architect, and maps out a low-level design of how the system will be constructed - the technical specification. This contains the detailed construction plan for the software, what modules it will have, what they will do, how they will interact, and how they will be made. Software design is largely about how the software will interact with the computer, but there is also the consideration of how it will interact with the user.
UX Designer: UX is an acronym for User Experience - how the user will see and interact with the software, otherwise called ‘Human Factors’, and originating out of Ergonomics. The UX Designer is responsible for providing input to the design process which ensures that the product is easy and logical for a person to use. Pretty much everyone who has used a computer has bemoaned the illogicality or unfriendliness of one software program or another - the UX Designer specifies the bridge between user and computer, the man-machine interface or user interface design.
Programmer: the classic perception of the software developer, the person who actually produces the computer program by taking in the requirements, high-level design, architectural requirements, technical specification, and the user interface design, and writing the computer ‘code’ that delivers the desired attributes and behaviours. The programmer must understand the mechanics of programming including variables, control structures, data structures, the vocabulary, syntax and grammar of the programming language to be used, how to assemble them, and how the language interacts with the machine. They use their knowledge of each of these to create the program envisaged by the analysts and designers. The programmer is also expected to ‘document’ the program by including comments which explain to other programmers how the code works so it can be maintained in the future.
“Has he finished yet?” you ask? Not quite….
Tester: As the software program is created someone must test it to ensure that it does what it is supposed to do. Typically this means creating a test plan from the requirements and design, then examining whether the software behaves as expected, and reporting back to the programmer any areas that need correction or refinement. The tester must be able to interpret the design just as well as the programmer.
Technical Author: Many software programs are expected to be accompanied by a document describing how they are used - the User Manual. Someone has to write it, and they must understand the functions of the software as well as the designers and programmers, and be able to convey how to use these functions in human language - Plain English for most of us. Not as easy as it sounds and most of us will have read instructions which appear to have been written by a chimpanzee in double-dutch.
Project Manager: Obviously producing software is complex, it involves many tasks whether executed by one polymath or a team of twenty specialists, and someone needs to keep all the activities on track in the right order and know what needs doing next.
Next time you advertise for a developer you might want to consider which of the many skills above matter most to you, make sure that you ask for what you need (even if the answer is “all of the above”), and verify the candidate’s relevant experience at interview. Most software development work is clearly not about programming. The other factor that you might want to take into account is that the programming language used by the programmer is a very small part of the equation in developing successful software. If you’re looking for an all-rounder then whether their main programming expertise is in C#, C++, Visual Basic, Python, PHP, Pascal, SQL, Fortran, or Forth is a small factor in the scheme of things, and if they can do all of the above then adopting a new language is unlikely to be much of a barrier.
Hopefully you now also understand why good developers cost so much - there’s a lot more to software than writing code!
