Coding, like poetry, should be short and concise.

You've ratified the design... right?

Step Four

Process

Which software development process do you use? If you can’t answer that, you are probably doing some variation of waterfall.

Waterfall

This is the oldest and most traditional model for building software. You can think of the Waterfall method as following each step of the SDLC sequentially. In order to complete a project you need to know up front every thing that needs to be done and in what order.

While the process is, on paper, simple and easy to put into a project plan. It is inflexible, has big up-front planning time is liable to slip due to unforeseen issues. What’s worse, due to the lack of interim feedback, you can end up committed to the wrong path without knowing until launch day.

Agile/Scrum

The Agile development process (and Scrum the most popular methodology) take a dynamic and iterative approach. Cross-functional teams work in “Sprints” to build and release usable software to customers for feedback. It’s all about releasing early and often; responding to the actual needs of your users. You don’t need a full list of requirements and a complete SOW before starting work. Instead, you start in one direction with the understanding that you’ll change course along the way.

Due to its dynamic and user-focused nature, Agile is often favoured by startups and technology companies. Using Agile and Scrum needs a solid understanding of the underlying process to pull off properly.

Incremental/Iterative

A middle ground between Waterfall and Agile. Both Incremental and Iterative follow the idea of creating small pieces of software and exposing them to users for feedback. However, they differ in what is created in each release.

• Incremental You start with an MVP with only a core set of features, then in each release add/update features based on user feedback.
• Iterative You start with a minimal implementation of all the planned features, then each release upgrades them across the board.

Can add a degree of flexibility to the development process, but you’ll still need to do the up-front planning and design work.

Coding

Bad code is difficult to understand. Bad code is more complex than it should be. Bad code is not easy to test. Bad code makes developers grumpy.

Clean code is understandable. Clean code is as simple as it can be. Clean code is testable (and tested). Clean code makes for better programmers.

Don’t settle for bad code. There are thousands of books about software development but it I had to pick one it would be Clean Code by “Uncle Bob” Martin. Buy it and make the development team read it.

Top tips for cleaner code

1. Favour Readability: Write code another human being can understand.
2. Be consistent: If you decide to do something a certain way, stick to it throughout the entire project.
3. KISS: Keep It Simple Stupid. Systems should be kept as simple as possible (but no simpler).
4. DRY: Don’t Repeat Yourself. Every piece of code must have a single, unambiguous, authoritative representation in the system.
5. YAGNI: You Ain’t Gonna Need It. Don’t add functionality that isn’t required.

Finally

Regardless of the process you are following, the goal is to stick to the SOW, avoid scope creep and build clean, effective software.