No matter how far down the wrong road you’ve gone, turn back.
In software development, the requirements and challenges that come up during your project development are never ceasing and ever-changing. Your software project depends on the skills, training, and competence of all the developers on the team.
A successful developer is the one with (technical) fitness, balance, and agility. Agility means being able to quickly adapt to the unfolding situation like a design that breaks sooner than expected.
Here are some tips that can help you:
- Use automated unit tests: Good unit tests warn you about problems immediately. Don’t make any design or code changes without solid unit tests in place.
- One test is worth a thousand expert opinions: Code without tests makes you feel uncomfortable. Unit testing is an investment. Invest wisely. Testing accessors or trivial methods is probably not time well spent.
A good design is a map; let it evolve
Let Design Guide, Not Dictate
Design points you in the right direction. It’s not the territory itself; it shouldn’t dictate the specific route. Don’t let the design (or the designer) hold you hostage.
A good design is accurate, but not precise. That is, what it says should be correct, but it shouldn’t go far as to include details that might change or that are uncertain. It is intent, not a recipe.
- Use it before you build it: Use Test Driven Development as a design tool. It will lead you to a more pragmatic and simpler design. You will always have a concrete reason for writing code. You can concentrate on designing an interface without being overly distracted by implementation details.
Write code to be clear, not clever: Express your intentions clearly to the reader of the code. Unreadable code isn’t clever.
Code you write must clearly communicate your intent and must be expressive. By doing so, your code will be readable and understandable. Since your code is not confusing, you will also avoid some potential errors. Program Intently and Expressively.
- Write code in short edit/build/test cycles: It’s better than coding for an extended period of time. You’ll create code that’s clearer, simpler, and easier to maintain.
Develop the simplest solution that works: Keep the code/design simple. Incorporate patterns, principles, and technology only if you have a compelling reason to use them.
Any fool can make things bigger, more complex, and more violent. It takes a touch of genius—and a lot of courage—to move in the opposite direction.
Communicate, Communicate and Communicate; Keep Others Informed: By accepting a task, you have agreed to deliver it on time. But, it’s not unusual to run into problems and face delays. The deadline arrives and at the demo, you are expected to show the code working. What if you arrive at the meeting and inform everyone that you haven’t finished? Besides being embarrassing, it’s not healthy for your career.
Publish your status, your ideas and the neat things you’re looking at. Don’t wait for others to ask you the status of your work.
By keeping others informed, you eliminate surprises, and they are comfortable they know your progress. They know when to provide you with helping hands, and you’ve earned their trust.
Keep your project releasable at all times: Ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment’s notice.
You will feel confident that anytime the boss, the chairman of the board, QA, a customer, or your spouse comes by the office to visit, you can show them the latest build of the software without hesitation. Your project will be simply always in a ready-to-run, stable state.
- Share code only when ready: Never check in code that’s not ready for others. Deliberately checking in code that doesn’t compile or pass its unit tests should be considered an act of criminal project negligence.
- Integrate early, integrate often:Code integration is a major source of risk. To mitigate that risk, start integration early and continue to do it regularly.
Deploy your application automatically from the start: Most developers tend to ignore deployment issues until the end of the project. The result is that they often end up deploying with missing dependent components, missing image files, and improper directory structures. So, automate deployment early.
Use that deployment to install the application on arbitrary machines with different configurations to test dependencies. QA should test the deployment as well as your application. Installing and/or deploying your product should be easy, reliable, and repeatable.
Reference: Book – “Practices of an Agile Developer”.
This article is originally published by the author on LinkedIn:
- Agile Software Testing
- Agile Software Process and it's Principles
- Difference between Agile and Scrum Testing
- Difference between Traditional and Agile Software Development
- Software Engineering | Agile Development Models
- Software Engineering | Comparison between Agile model and other models
- Software Engineering | Requirements Validation Techniques
- Basic fault tolerant software techniques
- Difference between Agile Testing and Waterfall Testing
- Software Engineering | Agile Software Development
- Software Engineering | Project size estimation techniques
- Difference between Agile Model and V-Model
- How to use GIT in Ubuntu ? (Part -2)
- Introduction to Ethereum - Part 1
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to firstname.lastname@example.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.