In Living with “Just Enough, Just in Time” Part 1 – Poor Execution, Fear, and Vanity, we discussed some causal factors and symptoms that could occur when we’re doing good work for the wrong reasons. Given how powerful those factors are, you may ask “why even bother to fight it?” There are some equally powerful reasons.
5 Reasons to do JEJIT
Doing “just enough, just in time” (JEJIT) benefits both you (as an engineer), your team, and your customer. Here’s why you should bother:
- Makes you a better engineer
- More progress visible to customer
- Less time spent speculating on the future
- Greater customer buy-in
- Less time spent on testing, QA
Becoming a better engineer: If you give it a shot, you’ll find that working with constraints/limits will make you a better engineer. Working with limits forces you to take stock of what must be done, prioritize it all, and then take another cut at figuring out what more you can cut while achieving the essence of what you’ve been asked to do. You are forced to learn good architecture & design (see SOLID) principles that let you write something today that is easier to refactor tomorrow.
More progress visible to customer: Would your customer be happier getting 3 valuable features that work well and look great in 2 weeks or only 1 such feature with an amazingly-engineered, robust architecture that they don’t see? Most will admit it’s the former. By failing to do JEJIT, you are effectively stealing from your customer – using their money to fuel your indulgence. In the end, your customer is less (potentially much so) satisfied and that could mean damage to your reputation or loss of employment. Is it worth it?
Less time speculating on the future: I’m sure we’ve all been in a design meeting when someone utters the dreaded “Yeah, but what if…” that would cause feature size to explode past your estimate? “What if 10000 users all log in at the same time?” “What if they drag 1000 files into the drop area?” “What if they’re running in IE 6?” My response to these questions is to ask “what if we spend 2 weeks over-engineering and under-delivering to our customer?” Because while there’s no guarantee that your predictions about the future will come true, it is guaranteed that the customer will be annoyed by your slow progress.
Please don’t take any of this as me discouraging meeting reasonable, customer-driven criteria. If the customer expects a million users on day 1, then it is reasonable to design for that. Otherwise, build for today and refactor when the situation changes.
Greater customer buy-in: If you create just the right features at just the right level of complexity/robustness, then you’ll find you’ll sooner have the right system that solves the customer’s problem. Don’t push the customer into features they don’t understand, as you’ll be doing it at the expense of their sense of ownership over the outcome. Greater ownership by the customer means they’re likely to want to continue being a part of the process, to help you make it better, to pay to make it better.
Less time spent testing, QA: Similar to the above. Keep it simple. Don’t forget the hidden cost of complexity: testing and maintenance. Less code, less complexity, simpler-to-use features, etc. all translate to fewer unit tests, fewer use cases, easier acceptance testing, and easier maintenance! Think about it, this is a compounding function: any unnecessary complexity you add will follow your team down the road, causing even more (often repeatedly) time spent unnecessarily testing and maintaining that unnecessary complexity.
I don’t encourage accumulating technical debt or making a bad situation worse. The next article will cover when it’s the right situation to do “just a little more, just in time” or even to do a little more up front.
Conclusion
Growth, time, frustration, customer engagement, and cost all take a hit if you’re not doing your best to do “just enough, just in time” (JEJIT). If that’s enough to make you want to learn to live with it, read my next article for some tips on how to do just that.
As a side-note, you’ll see that these benefits go beyond software. JEJIT isn’t a coding practice, it’s an engineering (even a lifestyle) principle. We won’t go into that here, but think about it!
