Living with “Just Enough, Just in Time” (Part 2)

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.

Doing what I want: customer's happiness falling vs. mine.
Doing what I want: customer’s happiness falls vs. mine.

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!

Living with “Just Enough, Just in Time” (Part 1)

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.

What they need vs. what we want to build.
What they need vs. what we want to build.

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.

Hello world!

Hello world, I’ve been engineering software for over 16 years now and it’s about time I started sharing out what I’ve found works, what doesn’t, and even just what’s on my mind. I’ll use these to solidify my core values, principles and practices as an engineer that I guide myself by since I find that if I don’t write something down it usually doesn’t really stick. Hopefully some of you find it useful, too.

If you have any questions about anything I post on my blog, leave a comment and I’ll happily discuss.

Quick Bio

I’m from the Department of Defense research and development (R&D) world, having spent my whole career as a DoD contractor working on and leading small teams of highly-motivated s/w engineers to build apps (as they are now called) that make operators safer, that save them time, or that allow them to do something they never could do before.

My teams have typically run on shoestring budgets with contracts lasting fewer than a couple years. We’ve had to perform our own testing, quality assurance, UI/UX design, marketing, and CI builds. To anyone who’s worked at a FAANG company, you would be alarmed by how much time my teams have had to spend doing things other than developing software!

I’ve worked in WinForms, WPF, ASP.NET, Unity, web (MERN), GIS / geospatial (ESRI ArcGIS, Cesium), Java, and even some AI/ML prototyping in PyTorch. A lot of my work has been developing prototypes that have gained traction and advanced to programs. We’ve been very successful in addressing the essence of a customer’s challenge and getting work to mature from that initial capability.

Scrump… Works???

Scrump is the ‘S’ from my first name and the first 5 letters from my last. The “works” was inspired by Lockheed Martin’s famous “SkunkWorks” advanced R&D shop responsible for successes like the P-38 Lightning, SR-71 Blackbird and F-22 Raptor. “Be Quick, Be Quiet and Be on Time” – Kelly Johnson, SkunkWorks.