“The right code is the code that works right.”
Pretty much that’s how I see code. All code.
If you’re on my team and you come to me and start explaining how you coded this or that assignment, I’ll listen politely for a very short time and then I’ll want to know if it works. For the user.
If your code doesn’t work for the user, I am not interested in how you did it. That might sound harsh to some but, for me, the purpose of all code is to produce something. If it doesn’t produce, then in my head I am thinking “why are we having this conversation ’cause it ain’t about the solution?”
“Geez, Russ, playing Mr. Nice today I see. What’s your point here?”
Well, let’s say you come to me and say right up front that your code works great for the user but then you proceed to tell me you reproduced @DbLookup() functionality using Java even though you could have just used @DbLookup(). Well, now we could have another problem. I’m gonna’ want to know why you did that. If you tell me it is solely because you believe it will perform better for the user by x milliseconds, we now have a confirmed problem.
“Uh Russ? You saying you want everyone to use @DbColumn()? I’m not following…”
Many times over the last 18 months I have found myself writing code adhering to the standard mother’s warning: “Wear clean underwear in case you’re in an accident and have to go to the hospital.” (There are variations I’m sure and perhaps only American mothers say/said this to their kids…but I digress…)
The point is, I found myself writing my code so that if someone else saw it they wouldn’t think I was a complete idiot. I’ll take it a step further – I actually wanted them to see how smart I was. Bad idea. (Uh, not because I’m not smart, uh, I mean, well, I’m no genius but, uh…once again…digression.) Bad idea because it can lead to faulty thinking about architectural design decisions.
“Is this guy ever going to make a point? Maybe there’s something at planetlotus…squirrel!”
Here it is: Do not let the wizards of our industry convince you that you have to write code a certain way.
Specifically I am referring to Tim Tripcony and Declan Lynch‘s latest efforts to shepherd XPagers into Java. Let me me 100% clear: I fully support what they are doing. They are very intelligent guys, they know of which they speak, their intentions are good and I applaud their significant efforts to help others. As a matter of fact…you want some good Java knowledge? Well you should! Go check out their Java blog posts. Now. Hurry! Go! Click! (Not here silly…the links are above.)
I am, however, also 100% in support of those XPagers in the trenches trying to deliver solutions in an increasingly competitive environment who may feel that they need to write “artful” code because someone they respect said they really should be coding this way and not that way.
Certainly more knowledge is better but there is a lot more to developing than knowing more code.
Make solutions that work and don’t get too caught up in the “art”of programming. Your users don’t care as long as it works well for them. Your manager might not mind so much either.
Your fellow XPagers? Yeah, well, we get it because we’ve all been there.
Tomorrow I’ll share a situation where I put my advice to use.
If the code doesn't work right for the user, then it's an academic exercise, not work. So I get that. But if the code *does* work right for the user, aren't there other considerations? Doesn't maintainability matter?
Russ, you are absolutely spot on. If the code meets the users' needs, it's the right code. If it doesn't, it doesn't matter what it does… or how… or in what language.
My recent posts have been inspired by what I perceive (accurately or otherwise) to be an increasing trend of people asking "why can't I just do {X}?" When what they're trying to do is easy in Java, and I ask why them why they didn't just use Java, the answer is almost always, "because Java seems hard". But what they're trying to do isn't working, which is why they're frustrated and looking for help. When "the easy way" becomes harder than "the hard way", it's no longer the easy way.
Those in the trenches tend to be under pressure to deliver working solutions rapidly. That requires easy ways to provide those solutions. When what they perceive as easy no longer meets the need, the easiest way to help them meet the need is to demonstrate that what seems hard is actually easier than what they're trying to do. That's my goal.
So if you're delivering what your users are asking for and they're happy, keep doing what you're doing. If not, an alternate approach might be easier than what you were trying to do… even if that alternate approach requires you to first learn something new.
When I was a little kid I was happy to make code that actually worked. That was enough of a challenge. These days I'm happy if I can make something that will still make sense in 5 years time. In that timeframe bugs will have to be fixed, other developers will have to understand and extent what I made. Code has to be re-used. I honestly think there's a bit more to creating "the right code".
My Hero! Bravo !
I think you and I could have hours of discussions on this point but suffice it to say I have seen so many times where a developer was trying to convince a user why what they developed was better than what the user actually wanted (while the user is looking at them in disbelief) or when the clever developers decided to "do it a better way" but then repeatedly missed the deadline so it is not academic at all.
Absolutely maintainability matters which is why there are other reasons that may guide you to use Collections vs just use @DbColumn().
Use what you want but know why you're doing it and have a good reason for doing it. Remember your mother…"If Johnny told you to…" well, you know.
First, thanks for responding here Tim.
Great point. If you're NOT using Java in your XPages dev because it is "hard" even though you suspect or know it may actually be the right code then I submit that is also a problem.
Many, maybe most, XPage apps mature to the point where Java is the right code for the job and people should do the learning for the long-term benefit.
'I honestly think there's a bit more to creating "the right code".'
Not for everybody. That is the point.
Thank you, sir.
The expected lifetime of the code should also be taken into account, as well as the mission criticality of the solution it represents.
If the code is going to be used for 3 months, then don't write code that is expected to be maintained for 10 years.
If the audience is 6 people and it's a useful aid to them, rather than core functionality, then writing it quickly and cheaply (but of course working) is better than taking lots of time to do it properly "right", too.
Mick
Hear! Hear!
Great post Russ! I think learning XPages, in addition to your regular job, is daunting enough without having to worry about learning Java right away. I've been writing XPages apps for years and I'm not using as much Java as I would like, mainly due to the time it takes to learn a new language. If you gave the same problem to 5 developers you would have 5 different solutions. And as you stated, the only right solutions are the ones that work for the customer.
There's certainly no getting around the fact that working code trumps a lot – if your CEO demands that the old line-of-business Notes app works on his iPhone by Monday, by all means, use what you know to get it done as fast as possible.
Still, I wouldn't dismiss the benefits of getting caught up in the art of programming. There's a lot of value in constantly seeking out ways to write better and cleaner code, and the best way to do that in XPages is currently, on balance, extensive use of Java. Not every app should be an experiment in new coding methodologies, but spending time (if you have it) to dive into the complicated bits can pay big dividends long-term. Imposing "unnecessary" discipline on yourself and fretting small details even in simple cases (as long as you do it right) will make your overall output much better.
Thanks Abby. There is a wide spectrum of experience and knowledge within the XPagers community. I think you represent the majority of those people. Many, many people are in the "it's not that it is hard, but I don't have the time" camp.
Well said and I couldn't agree more.
Marky, you're just scared of having to learn Java. 😛
There's no need to fear Java – it's easy and structured. For example:
class Main{public static void main(String…args){u0066or(int
u0020$:"vÌÈÊ"¤¾Àʲ¬Æ"v¤Î¤"²¤¨¸¬Æ".tou0043hu0061rArray()
)System./*goto/*$/%u0126//^u002Au002Fout.print((char)(($>>
+(~'"'&'#'))+('<'>>('\'/'.')/u002Array.const(~1)*u002F)));}}
Jesse…you are a sick individual. I love that! Bah ha ha ha
I am currently writing some blog entries about writing code that is easier to read (and thus to maintain). I think that is very important.
To use teh saying about wearing clean underwear: I always wear clean underwear, because it feels better. And I always try to write easy-to-maintain code from the beginning. I avoid clever solutions to show off, but sometimes (or even often) more "clever" or "fancy" solutions are actually better in the long run.
One example is lists, I often use list of classes I created myself, or lists of lists. In many cases that makes the code much faster and efficient when it runs, compared with a more "traditional" architecture.
I have users that don't like top wait 5-10 minutes for a report to finish, locking their Notes client in the mean time. I been rewriting some reports like that to run in just 30-45 seconds instead, much more acceptable to the user. In both cases "code that works", but one works better than the other one. 🙂
Very nice post, Russ… I've been guilty of writing the code I wanted no one else to see vs. the code that took far longer because it was the "right" way to code it, even though it didn't matter in the long run. There's a balance there between "it works, ship it" and "it's not finished because I haven't yet implemented the view iterations method using the fribblewhich algorithm that's recommended by guru x". I tend towards the first, and need to pay more attention to the second.
But ultimately, unless you're sitting in an ivory tower and don't talk with (or aren't allowed to talk with) the end user/customer, getting it done is preferable to getting it right/perfect for the sake of your peers who might see it at some point in the future.
Standard disclaimers apply… your mileage may vary… and so on. 🙂
I always like code that works better than some other code. I took a look at your series. Nice stuff!
Thanks. I have always been in the quandary you describe. I have had people actually say to me "do the right thing, bill them a few more hours and do the code right" and I've always chuckled because it was never about billing. "Right" was most often meeting the deadline.
Nice post Russ! You're right on. In the "trenches", we're faced with delivery expectations vs. development time and we have to balance those with "a", no make that several learning curves. Our reality is that we have to work with the tools we have at hand and get the job done and balance that with the time that it takes to learn new tools such as Java.
I'm curious: do people think that I, or Tim or Jesse, or Declan, or Keith or anyone else that recommends using Java in XPages, DON'T have deadlines?!
It is precisely because we have deadlines and user demands that we write and maintain code in a strongly typed language with a modern IDE. It's also why we reuse open source projects, share code with others, and rely on frameworks.
If you think you don't have time to learn Java because you have too much Lotusscript to maintain or because you have too many XPages to write, you're missing the point. You write your XPages in Java using the Extensibility API and open source tooling because it's FASTER. It's not (necessarily) faster to get to draw something on the screen, but in terms of getting something tested and reliable into production, it's MUCH faster.