When you hear the phrase “just enough, just in time” (JEJIT), what comes to mind? For many, it’s not pleasant…

• Wasted effort – doing good work knowing I’ll have to replace it later
• Incomplete, unpolished
• Short-sighted, unskilled, lazy

Sure, many software developers and engineers have run into problems adopting JEJIT. Some of these engineers may even have fully bought in to the principle and still had a bad experience. But why? Poor execution, fear, and even vanity all play a part.

Poor Execution, Fear, and Vanity

Well-intentioned, poorly-executed practices pushed by leaders, QA, standards organizations, etc. can all drive us to do more work than we have to when applied incorrectly. Why are we spending a week doing DB work when we haven’t even proven the core concept, yet? Do I really need 100% code coverage for 4-week prototype code? Why are we spending hours on a logo when no code’s been written, yet? Ask yourself at each step whether the work you’re doing is to meet your customer’s current priority or if it’s to satisfy something else.

Fear of waste, of not knowing can drive us to implement architecture and features far beyond the use cases we were tasked with. “What if the customer decides they want to send image message someday? I’ll have to change my API logic!” You know what, that’s fine. If that day comes, yes, you will have to refactor some code. If you stick to SOLID design principles, the effort should be minimal. Think about it: even if you did modify your API to support future use cases, it’s possible that you made some bad assumptions and will have to refactor that code anyway. Doing more work as a result of not knowing something is usually the wrong approach.

Vanity can be the most difficult-to-overcome cause of doing more than we should. We want to be the best, to be right, to be flawless. We self-indulge and obsess over doing it just right to the point that we get it all wrong. I’m sorry, but this isn’t about us. Let it go. Move on. We’re here to deliver value to the customer, not to make ourselves feel good at their expense.

Conclusion

So how can we help ourselves and our team move beyond these environmental and behavioral blockers to realize the benefits of JEJIT? Why should we even care to? My next post will cover why it’s crucial for you to deliver “just enough, just in time” as well as provide tips for learning to live with it. It may take some getting used to, but your customer and future self will love you for it.