Based on current and past experience, this is a brain dump of what I think a development project needs to put it in the "Good Place".
This is a personal opinion and as such is open for discussion. In the end my primary goal is to help recognize opportunity to make the world a better place. It is also part vent to help me alleviate some frustrations :-D
This is the starting point for any project.
- What is this project all about?
- How do I get this thing to work?
- ''Why'' do I want to be involved?
Whether it's joining the company or joining a project, each team should ensure that they have a proper on-boarding guide. The last person to join the project should always ensure that this is up-to date and easy to follow.
I should strive to leave things in a better state than how I found them.
Well Duh! But this should be our mantra whenever we put a Pull Request in!
Slipping into a code vent, but any time we submit a request to enhance the project, we should know that the solution will build and has been tested sufficiently to ensure that we are not breaking the Boy Scout Rule!
If it can't be tested then we are doing something wrong! Our aim is not only to ensure somethings works but to ensure that anyone handling our solution can run scenarios and if they make changes, have confidence that the system still works.
Every project should aim to provide scaffolding for Unit / Integration / e2e tests, where possible.
It is every team member's responsibility to ensure things are tested! An automated test engineer can provide scaffolding and frameworks but they should not be contributing solely to that code base.
Controversial I know! But wherever possible, we should try to find solutions that don't tie us to a vender, unless the benefits of doing so outweigh the agnostic advantages. By its very definition, tying yourself to something reduces your flexibility and potential available to you.
''Dev Ops'' is dead because it was never a thing in the first place. Every engineer has always found ways to automate and to script out menial tasks. Any solution should provide simple, automated ways to build, test and publish itself. Engineering is about making engines to "artfully bring something about".
The organization's role is to help teams and team members work to the best of their ability and not throw roadblocks in the path of success.
No-one would expect a builder to build a house without the proper equipment, so why expect an engineer to build you a solution if you don't provide them with the correct tools? Invest in the team and help them make something beautiful!
If anyone has to find workarounds or use systems that are out of date, then there is a fundamental problem within the organization!
Help them understand. Help them be ready for it.
Fortune favours the bold
An organization is successful by being creative, taking calculated risks and adapting to change.
As an organization you hired these people to do a job. If you can't trust them to do this correctly, why did you hire them in the first place? Creative people need the ability and freedom to drive new things. Look at Google and how many new product ideas have come from the trust in their engineers.
Risk should be always be a balance. Weigh up the potentials of doing something vs not doing something / having something vs not having it. Can adequate safe guards be put in place that don't cause a bigger detriment than the potential risk?
Every solution we create has compromise or reasons things are done, yet if we don't tell people why, they can never understand our decisions.
Should be discoverable and documented. Hiding away useful features and functions is the same as them not existing in the first place.
Every successful business started with an entrepreneur. It doesn't matter how big or small your project is, if any opportunity presents itself to create advancement or innovation we should be obliged to explore it. Minimize risk by experimenting in smaller projects.
We learn from others and from what others have done and experienced, this applies both inside and outside an organization. But how can others learn from you, if you don't give back?
Internal projects can cut corners and afford to not follow best practice. Opening up to everyone means you have to follow best practice, you have to be open to scrutiny and create documentation that everyone can follow, otherwise no one will want to use your solution.
As part of on-boarding any new team member, there should be clear signposting to the standards to adhere too and where any cross-cutting concerns can be found.
Resources should be shared and freely available to all team members. Creating isolated and insular projects leads to constantly re-inventing the wheel and not learning from other people's mistakes.
Read the agile manifesto and look at how it can be applied to all aspects of the a solution e.g. architecture
We should create an environment where people are encouraged to speak up. If you don't know what an acronym means then ask!
Community work better than isolated teams. Spread the knowledge, ask for different points of views from other teams. If you can't explain you problem, do you understand the problem?