Fast vs Quality vs Cheap

It's surprising how much control we have as developers, in determining what kind of quality work we can deliver for our clients. Yes we're almost always restrained by budget and deadline, but it doesn't mean we should ever deliver a cheap, patch-fest nightmare for our clients.

Like every good tactician, more time spent on pen and paper (or whiteboard) than fingers on keyboard is often a good sign. A good developer should always spend enough time to familiarise themselves with the system architecture at the beginning of every project. It doesn't necessarily mean we should understand the entire ecosystem to the bone, but we should at least have considered all the important aspects before we jump on the keyboard:

• "In a nutshell, the solution architecture relevant to this project's scope looks something like THIS *draw a diagram*"
• "This is the mother-ship project for my business logic, that is the application project for all my front-end related stuff"
• "I shouldn't create this service because it already exists somewhere else, must reuse all the things"
• "This is how existing services/modules/pages were implemented, must keep mine consistent"
• "Oh, these huge piles of static data are taking a long time to load, must cache all the things"
• "Must segregate my services / controllers this way to allow extensibility going forward"
• etc.

Implementation should be the last thing we worry about in an unfamiliar environment. Being able to identify and map a project architecture is the key to deliver quality code fast.

Each project has different "colours" and complexities, but are always fun to solve. A time-pressed project doesn't need a perfect developer, it needs one who can adapt quickly, be effective (ie. productive and efficient), and be able to solve it on time.

 

Delivering unmaintainable work on-time is productive but not efficient. While this might please the clients better, we're actually choking ourselves to death in the long run. It's like putting a carpet on a sink hole. It might look nice from the outside, but someone will eventually step on it and plunge to death.

 

Delivering a perfect piece of code months behind is (probably) efficient but definitely not productive. The client will walk out the door and find another person who can do the job. As simple as that.

 

Some projects are a 5000-piece puzzle with 3-hour limit, some others a 500-piece with 30-min limit. Regardless, always solve the edges first.

Well, it doesn't matter. At some point we all would have to comply with others' estimations. Sometimes they're good, but often they're bad. We'll just have to make do. As we build experience from our past projects, we should become more proficient in building solid code skeletons that allow flexible implementations faster. Hard-code your implementations but never your code structure. Put to-do comments, references, etc and isolate your day-one "mess" so that they're easy enough to refine on day two.

There are many other factors that can contribute to the success of a project and us developers should be one of them. Never say impossible but do say "it depends...". Always map code architecture at the start, and adjust implementations to deadline.