What are the SDLC activities you perform as a Java developer? Why is building a software more complex than building a bridge?

Don't get overwhelmed by this activities list. This proves why employers favor experience to just academic qualifications alone. It also emphasizes the fact why good technical skills must be complimented with good soft skills and right attitudes get things done as a software developer.

I also vividly remember my first job interview for a Java developer role where I was asked if I understand SDLC. My answer was a big "No", and then followed up with a question to the interviewer -- out of curiosity, what is SDLC? The interviewer response was -- "it is complex, and cannot be explained in a few sentences".

Why is building a software is more complex than building a bridge? 

Building a bridge is a concrete concept, where you can touch, walk on and feel the bridge. Bridge building has a well defined set of rules and processes to follow.

Whereas developing a  software is an abstract concept, where abstract requirements from the users, stake holders, and business analysts need to be converted to rules and processes to accomplish the final product that meets both functional and non functional requirements.  Some of these rules can have many permutations and combinations, and makes it impossible to cater for all possible scenarios by the developers and testers. Software development environment is very dynamic with multiple streams of projects working on the same code base by creating so called branches. Environments can easily become unstable if proper control and processes are not in place.

Let's see the SDLC activities from a Java developer perspective.

Pre-development activities 

• Review business requirements document (aka BRD) along with other functional and non functional specification documents prepared by the business analysts.
• Review and understand the baseline architecture created by the architect(s).
• Create technical specification documents and get them reviewed and signed off by the relevant stake holders like architect(s), team leads, testers, business analysts, etc. Use tools like Confluence or Wiki for the documentation. Use appropriate diagrams in your documentation like
  • Physical and logical conceptual diagrams to give a big picture.
  • Entity Relationship Diagrams (ERD) if you have new database tables.
  • Relevant class, sequence, state, and component diagrams.
• Choose the  
  • programming languages to develop in (e.g. Java, JavaScript, CSS, HTML, Groovy, etc)
  • frameworks (e.g. Spring, Hibernate, angularjs as MVC framework, JUnit for unit testing, Drools as business rules engine, etc)
  • tools (Eclipse IDE, Maven for dependency management, build and deploy, Subversion for code repository, Jenkins for continuos integration, SonarQube for code quality, DBArtisan/SQLDeveloper/DBVisualizer for database management, BeyondCompare to compare files, Putty/Cygwin/MSYS/MobaXterm/WinSCP as Unix ssh emulators, etc )
  • integration servers (web Methods, Oracle Service Bus, Websphere MQ, Apache Camel, Mule, SAP, Pega BPM, etc) & database servers (e.g. Oracle, Sybase, etc) to be accessed.
• Perform impact analysis from the requirements where required.
• Perform capacity planning from the non functional requirements to see if the new applications could be deployed to existing infrastructure or new infrastructure needs to be commissioned.
• Listing project risks, and  probability of happening as less likely, likely, and most likely, and ranking the impact of a risk as low, medium, and high.
• Listing design alternatives, pros & cons of each alternative, and describing reasons for selecting a particular approach.
• Decide if new applications need to be built or existing applications can be enhanced.
• If new application, create a new maven project in the subversion trunk. If enhancing an existing application, create a new branch for this project in the code repository like subversion or GitHub.
• Set up the continuous integration server to get into the rhythm of build, deploy, and test, SonarCube server for code quality, Maven repository and Nexus for jar dependency, software version control, and release management.
• Follow up on infrastructure requirements like requiring new hosts, more hard disk space, load balancers, single-sign-on security requirements, domain names, system monitoring via nagios or tivoli, data archival and retention, auditing via triggers and logging via splunk, etc.
• Raise access requests to all relevant environments, servers, and systems.

During development activities

• List all components that need to be newly developed or enhanced in the detailed technical specification document. For example, web components, web services, batch jobs and scripts for ETL (Extract Transform Load), integration with SOA, BPM, or MOM, etc,
• In an agile project, you develop in iterations, and get into the rhythm of  build, test (i.e. write unit and functional tests), release, and deploy. 
• Provide environment and test support to the testers by fixing any environmental issues and coding bugs. Tools like JIRA, HP Quality Control, can be used for issue tracking, control, and management.
• Regularly rebase your subversion branch with trunk to synchronize with changes from other projects to the shared code base.
• Continuously  update technical specification document with relevant details as you build and deploy in iterations.
• Perform peer code reviews via tools like Crucible.
• Continuously refactor and improve code quality as a result of reviewing the Sonar code metrics, peer code reviews via crucible, and self code reviews.
• Use code coverage tools to ascertain unit test coverage and improve on the code coverage percentage.
• Continuously follow up that infrastructure requests have been met.
• Perform system outage testing (e.g. to ensure load balancer is performing as expected, proper timeouts are configured, and service retry mechanisms are in place), penetration testing to fix security vulnerabilities, performance testing to ensure that SLAs specified in the non functional specs are met, and cross browser compatibility testing.
• Write or enhance scripts to ensure proper data archival, auditing, and monitoring is in place.
• Perform Maven release process with proper artifact version numbers as a readiness to be released. 
• Promote your applications through different environments like test, integration test, and stage.

Post development activities

• Wrap up the tasks that you started previously during development like documentations, infrastructure requests, non-functional testing like penetration testing, outage testing, cross browser compatibility, and performance, etc. 
• Write support hand over documents and user manuals.
• Get final sign-offs and approvals from the relevant stake holders so that the applications can be promoted to production.
• Write implementation plans and other production ready tasks like lining up resources, sending out communications, etc.
• Perform diffs of your production deployment ready artifacts like war/ear files, windows zip files, RPMs (Red hat Package Manager), etc against artifacts currently in production with tools like beyond compare to ensure that the differences are only changes that you added. This is required for enhancements of existing artifacts.

Post production release activities

• Merge your code changes in the branch back to trunk.
• Send communications out to relevant cross functional teams.
• Tidy up any other loose ends in terms of documentation, code or environment clean up tasks, etc.
• Conduct project retrospective sessions to see what went well, what did not go well, and how things can be improved next time.
• Move on to the next project.

Are you overwhelmed by these tasks? Don't be afraid. It is a team effort. There will be cross functional teams with varying technical strengths. So, you will be performing some tasks yourself, and taking on the role as a facilitator for the other tasks where you need to chase people to get things done. No wonder why you need to have good non-technical skills to get things done as a Java developer.

Can you list any other developer activities not covered here?

Interview questions and answers on SDLC (Software Development Life Cycle)

I just had been to a job interview and I was grilled on this very topic. The interviewer was passionate about this topic. I will have more posts on SDLC by providing additional links here. If you are an experienced developer, these questions and answers should be pretty easy. If you are a novice, this will give you a high level overview. It is good to be familiarized than have no idea at all. Q. What does SDLC stand for and what are the different phases? A. SDLC stands for Software Development Life Cycle, which is a process of building an application through different phases.

Q. How will you go about choosing the right SDLC for your project?
A. 

• Firstly choose a base methodology: from a number of SDLC methodoligies like Waterfall, RUP (Rational Unified Process), SCRUM, XP (eXtreme Programming), etc. If you already have a SDLC methodology in place, analyse the existing deficiencies. This can be done by interviewing users of the system.
• Secondly, analyze what other best practices can be adopted from the other SDLC methodologies. For example, you can adopt best practices like daily stand-up meetings, iterative development, peer code reviews, and test driven development with waterfall as the base methodology. 

Here are a few factors that will help you decide what SDLC methodology is right for your project

1. Understanding how the business is structured. For example, are the business units siloed by products? the culture of the organization, etc.
2. Complexity of the project. What is the size of the project team? How many streams are there?, etc.
3. Nature of the project. New greenfield project versus enhancements and maintenance to existing systems.
4. Capabilities of your engineers, tools, and current processes in place.


Q. What are the benefits of peer code reviews?
A.

1. Pick up issues and bad practices in others' code.
2. Get more familiarized with others' code.
3. Learn from others' code.

Q. Why would you use continuous integration?
A. 

• One of the key practices in agile processes is collective code ownership. The continuous integration supports continuous design and collective code ownership. The developers will be required to integrate others' changes more frequently.
• The continuous integration build process is a mechanism to find and eliminate problems from code changes as early as possible. The continuous integration motivates developers to check in code as often as they can, and avoids any stale code. This will also result in reduced down time.

The best practice for continuous integration is to perform the integration of others' changes on a your local workstation before your code escapes into the build server. It’s okay to break the build once in a while, but it hast to be quickly fixed. The build should never spend the night in a broken state.

During integrating others' changes, you are also peer reviewing and familiarizing yourself with others' changes.

Q. What are the pros and cons of pair programming?
A. 

Pros:

1. Continual design and code review that leads to more effective solution and effecient defect removal rates.
2. Programmers can learn from each other.
3. Improves communication and can build better teams.
4. The programmers will be more disciplined and encourages the agile principle of collective code ownership.
5. Fewer interruptions as people who are working in pair are less likely to be interrupted than someone working alone.

Cons:

1. Pair programming can double code development expenses.
2. Hard to get all programmers to embrace it. It takes the programmers out of their comfort zone.

Q. What are functional requirements? What are Non-funcrional requirements?

A. Functional requirements  are captured in a document with use cases or via story boards which contain what a certain system has to do to achieve a number of user objectives.This task is carried out during the priliminary stage of SDLC. For example, allow investors to place buy and sell trades. Prior to placing trades, the user inputs need to be validated, etc. Use case diagrams are used to capture the user experience.

Non-functional requirements addresses aspects that a software will never function properly without them. Response times, security, reliability, accuracy, high availability, and cross browser compatibilty are examples of non functional requirements. The Non functional requirements decide how a software will be percieved by its users. Users wouldn't be happy using a system that is not highly availabled and riddled with security holes. 

Q. What are the different types of testing?

A. 

• Unit testing where the developers test their code by writing unit tests. Code coverage tools are used to determine the extend to which the code is covered.
• System integration tests are generally conducted by the developers to test integration of their code with external  CMS (Content Management) Systems like Vignette, CRM (i.e Customer Relationship Management) systems like Siebel or Salesforce, and any other third party system. During development, the external systems can be mocked, and during system integration testing, both happy path and unhappy paths like service failures, service timeouts, sticky versus non-sticky sessions, and service retry need to be tested.  
• Cross browser compatibility testing.  The modern applications are very rich in client experience and use lots of client side scripting like JavaScript. So, it is imperative to perform browser compatibility testing to ensure that the code works with major browsers like internet explorer, Firefox, Google chrome, and safari. There are tools like BrowserShots, IE Tester (for various IE versions), Adobe Browser Lab, etc.
• Performance Testing – uses automated tools that are designed to test and tweak system performance. For example, use JMeter to write performance testing scripts.
• Load Testing – helps determine how well the product handles heavy demand for system resources. For example, how well a trading system handles panic sells during a financial meltdown. 
• Security Testing –  to guard against accidental miss-use, hackers, or known computer malware attack. For example, using a tool like Skipfish from Google.
• Alpha Testing – is conducted after the majority of the software functionality is complete but before end-users are going to be involved. 
• Beta Testing – is conducted after project code is complete. 
• Acceptance Testing – is carried out by the testers, business analysts, and users to ensure that the system meets the functional and non functional requirements. The software is packaged and released with release candidate version numbers like RC1, RC2, etc to the user acceptance testing environment.
• Regression Testing – is conducted to check if bug fixes have been implemented successfully. Also checks for the presence of new bugs or flaws that could have been created from correcting the original errors and ensures no baseline functionality has been lost.

Other Relevant Links

• Agile methodology or development practices interview questions and answers 
• Agile development methodology: theme, epic and user story 
• Pros and cons of agile development methodology and agile principles
• RUP Interview Questions and Answers -- overview
• What are the SDLC activities you perform as a Java developer? Why is building a software is more complex than building a bridge?