A Developer’s Job Mirrors The Project Lifecycle
A Developer’s Job Mirrors The Project Lifecycle
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
The topic of what is a software developer’s job comes up quite often. Obviously, they are paid to write code, but that is a very narrow definition. As a developer gets more senior, they are asked to design the various components of a system, instead of just coding a task. With agile development, the idea of unit tests crept into the job description as well. Lastly, the developers need to be able to deploy the application in a local development environment on their computer as well as possibly deploying it to a testing server as well. So, even though the primary task of most developers is to write code, their whole job mirrors the software project lifecycle of Analysis, Design, Development, Testing, and Deployment.
As a junior-level developer, analysis is limited to the tasks assigned to you. You need to review the requirement and understand what needs to be done. This is a fairly simple task, and very limited in scope. This allows you to affect small portions of the system as you learn and grow. As you become more senior, analysis is done at the groups of features because the group of features could affect the design of the system as a whole. As you review the features, you may start thinking about the types of technologies used. Does it make sense to implement a message bus or should you use a publisher/subscriber (pub-sub) model? This starts to bleed into the basic design tasks as well.
Design is the basic task of determining what components and methods to create , and how they interact. For a junior developer, this is typically limited to just some methods within an object, or a very small group of objects. Senior developers get the more interesting task of determining what the major components are that make up the system and potentially breaking these larger components into smaller ones. The design is also greatly affected by the technologies being used. Continuing with the same example, a message bus implementation will require components that listen to the bus and parse messages before passing information to the core business objects. In a pub-sub model, the business objects themselves could be the subscribers and will receive notifications directly.
This part of the job is the reason you became a developer in the first place. The majority of a developer’s job is to write code, and many take much joy from the process. Junior and senior developers all write code typically, though a senior engineer may write code for more interesting problems, while the junior developers are focused on less critical tasks. There are a few important things to note. First, development in a project is normally one of the longer phases. Second, writing code is likely 50% or more of the developer’s day. This keeps most developers happy enough, but developers tend to complain a decent amount anyway.
For the early part of a developer’s career, testing will be considered the bane of their existence. However, as agile processes have gained adoption, a lot of this can change. Unit tests are being written by most developers now, even in the most waterfall-process-driven companies. The value of unit tests is very high, and there are huge benefits of having unit tests during the maintenance of a product. I have written before about the importance of unit tests, and no developer should consider their code complete without some level of automated testing. Another part of a developer’s job is writing scripts that make the QA process easier. Developers may need to script automated loading of data, or even creation of the entire testing environment. The benefits of this may not be obvious, but how much time is lost in creating an appropriate environment to do testing in, and recreating that environment when QA testing needs to be repeated.
Production deployment, or even deployment to the QA environment, is a current thorn in my side. In many larger organizations, there is likely an IT group that controls the production and QA deployments of all applications. This means that the development team needs to write detailed instructions on the correct way to deploy the application. In smaller companies and consulting agencies, developers will need to script the deployment activities so that the installation is as simple as running one command. Why is this needed? There is always more than one thing that needs to be done to install an application. At the minimum, there is basic configuration that needs to be modified for the installed application. In some cases, there is some data initialization that is required in order for the application to function correctly. If the installation is a little more complicated, there is the application deployment, and copying files to various locations. All of this is fairly easy to script and allows you to recreate a development, test or production environment very quickly.
In larger companies, developers may not get a taste of all of this, and it is disappointing. Without feeling the pain of each part of the job, you do no understand the difficulties within each phase of a project. If you are a product development company, you should be deploying your own application to determine how difficult or complicated it is to install. As a developer, you should be writing tests in order to feel the pain that QA goes through when testing the application. If you are not doing these things, then you are not really doing the full job of a developer and will be missing some experience along the way.
Published at DZone with permission of Robert Diana , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.