This content originally appeared on DEV Community and was authored by ·ſ
There are many acronyms and catchy taglines you probably don't know.
Disclaimer
While some practices may appear creative, you might find others trivial. Besides, some could have disappeared in 2021. Popularity doesn't matter here.
Think Outside the Box
This tagline is a timeless message that invites you to think differently. Apple helped in popularising it even more with its famous advertising slogan "Think different."
It means the opportunities are left for those who keep looking, don't give up, and think outside the stranglehold of society that everybody knows.
Programming, Motherfucker
Programming, Motherfucker rejects XP, Scrum, Kanban, Waterfall, and "anything that is getting in the way of.... Programming". It's a radical approach that wants to destroy classic software development methodologies, claiming they don't work at all and even humiliate programmers.
The manifesto has been signed by Zed A. Shaw on programming-motherfucker.com.
In practice, it can lead developers to introduce breaking changes regularly.
Eat your own dog food
You might be seduced by "Programming, Motherfucker" and other approaches, but don't forget to experience them first hand.
This principle is not limited to software dev and is also known as Dogfooding. Roughly speaking, it means the employees use the company's products. Marketers and advertisers often have similar approaches.
The main goals are:
- Prove the company's confidence in its own products
- Improve the overall quality
- Enhance the user's experience
- Speed up iterations
Big Design Up Front
It means don't rush the implementation. Don't start with code. By taking more time to think about things, you can save lots of dev issues and dead ends.
It's a bit counterintuitive, especially for beginners, as you might want to prove you can translate any idea into code, but even in the best-case-scenario, the feature might fail because you didn't involve the right people at the earliest stages, making the couple hours you've spent on your POC (proof of concept) pretty useless.
The Least Astonishment
Please keep it simple when you code. You'd rather use intuitive structures and algorithms than hacks and clever syntaxes.
The naming conventions can be pretty decisive in this perspective. If you create a class that handles Payments, then don't name it "Subscription."
Be careful, though, with too generic names, as it might be challenging to use for other developers as well.
Premature Optimization is the worst
Do you want your code to be perfect? Well, don't make it a general rule. While optimization will be necessary for the successive iterations, doing it at the very beginning is a terrible mistake.
It would require much effort and time, while the first cycles usually include lots of modifications. You could even introduce nasty regressions with premature optimization.
The Law of Demeter (LoD)
The LoD is the principle of least knowledge:
- Each unit should have limited knowledge about other units: only units "closely" related to the current unit.
- Each unit should only talk to its friends; don't talk to strangers.
- Only talk to your immediate friends.
In other words, the idea is to decouple classes and entities and reduce connections between them. Projects that follow this principle may have lots of relatively small modules and packages.
The Twelve-factor app
12factor.net is a list of modern principles for software-as-a-service apps:
- Codebase: One codebase tracked in revision control, many deploys
- Dependencies: Explicitly declare and isolate dependencies
- Config: Store config in the environment
- Backing services: Treat backing services as attached resources
- Build, release, run: Strictly separate build and run stages
- Processes: Execute the app as one or more stateless processes
- Port binding: Export services via port binding
- Concurrency: Scale out via the process model
- Disposability: Maximize robustness with fast startup and graceful shutdown
- Dev/prod parity: Keep development, staging, and production as similar as possible
- Logs: Treat logs as event streams
- Admin processes: Run admin/management tasks as one-off processes
The Pareto principle (80% - 20%)
Only 20% of features are essential to 80% of the users. Reciprocally, teams usually spend 80% of their time on 20% of the application.
Theoretically, with this approach, 80% of the application could be developed, with only 20% of the time allowed in the best scenario.
Reward The Player
It's a game design principle that highlights positive reinforcement. It's not uncommon to see the same approach in software development, as platforms can use scores and badges to improve the users' motivation.
The technique is known as gamification. Apps offer unique capabilities that unlock pretty cool features to the most involved users, just like it's done in video games.
Conclusion
Hopefully, you learned some principles here. The idea with those approaches is to find the right balance.
Photo by Joshua Sortino on Unsplash
This content originally appeared on DEV Community and was authored by ·ſ
·ſ | Sciencx (2021-10-19T11:08:30+00:00) Catchy dev taglines you probably don’t know. Retrieved from https://www.scien.cx/2021/10/19/catchy-dev-taglines-you-probably-dont-know/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.