This afternoon I had to move our development and UAT environments to a new Salesforce sandbox. This one is supposed to be the place we'll be doing our development and releasing code to the Salesforce Team's promotion process, so it made sense to get it right and just do it.
The process wasn't hard - I've got it all documented from the last time I had to do this, so it went pretty smoothly. Just needed to get it done.
I've been thinking a lot about a conversation I had with my manager about producing versus well thought-out design. He seemed to think that it was a trade-off, and the more I think about it, I think he's wrong. Oh sure, there are tons of trade-offs in engineering and software development, but there isn't a trade-off in putting out good code every day, and doing it "right". There can't be.
If I'm putting out a bunch of features in a day - every day, then they can't be hacks, or some day they are going to catch up with me and make it impossible to go forward. That's not sustainable. What is sustainable is to make sure that you're writing good code… well thought out code… but you're doing it like you mean it.
For example, today I had to go through a lot of code written by one of the Code Monkeys that was really slapped together and included no documentation at all. It was a rules system and it wasn't working cleanly because the methods were quite the rules, and they weren't quite the factors of the rules, so there were nasty dependencies, etc. that made it very hard to figure out what was happening and how to fix it.
I had to clean it all up, make the methods either condition checks or rules, and all rules simply were collections of condition checks, had to clean up some of the tests based on the logging strings, and in general, just make it a lot cleaner.
This didn't take me long, and it took me a lot less time - even under pressure of fixing bugs, then it did to create it by the original author. So it's not about the time required, it's the actions that are taken.
There's no trade-off here. You have to be good at what you're doing or you're going to make a mess. Period.
I can see when code has been lazily copy-n-pasted and not really incorporated properly. I can see when coders leave in hard-coded values when they thought they were changing things out. It's not all that hard. This morning I've been doing quite a bit of this kind of bug fixing. It's not all that hard - it's pretty easy stuff to spot, but it makes me sad for the guy that wrote it, because I'm not going to see him in the same light as I had.
Also, comments would be nice when I'm digging in a new web framework (Sinatra), and I really need to get up to speed on these Ruby web systems sooner rather than later as it's going to become more important to me that I'm able to write these - as opposed to just bug fixing them.
I suspect they just don't care, and aren't motivated in the least to care. So I really have to try very hard not to think it's who they are - just how they are responding to the job.
I know I've written about my lack of understanding with the apparent desire by Ruby devs to write no comments, but today I officially said out loud: "This is my grown-up Christmas wish: Comments in the code", and I really mean it. I was in the middle of trying to figure out a Sinatra app, and the entire file had one comment, and it was a TODO: as opposed to mentioning what the code was actually doing.
I think I have an idea why this is the case… face it, comments can "ruin" the look of code. It spoils the "line" and "flow" of the code. The only reason they are there is to save time for the developer trying to understand what's happening. But suppose you had a developer that didn't care about the time it took to understand the code?
Then you'd have a person that didn't like comments.
It's not about caring about the "next guy". It's about the beauty and ascetic of the code. And if you simply don't care that it takes you more time to figure things out, then there's no downside. I didn't understand - until now, that it wasn't that they were lazy… it was that they simply didn't care about getting things done.
Certainly not in comparison to the style and look of the code.
Which explains so much.
Why is it that there's so much ping-pong and pool played during regular hours? Well… if you're not concerned about delivering things, this is easy - you have friends here, and the table is right there. It makes perfect sense when you realize that they just don't care.
But Why? That's the biggie, right?
I have a theory, and it's based on a conversation I had with someone here. The focus is on sustainability. If you want to keep people at a position, you pay them well, staff the projects well, and expect a moderate amount of work from them. This allows them time to learn, grow, and rest - while getting a little work done. Consequently, they don't see "management" sweating about a few lines of code… or a few hours to re-learn what it's doing. So no big deal.
This might be the wave of the future, I have no idea. But it seems to me that in comparison to the other places I've worked - including my own company, this is only sustainable as long as they have money to burn. When money gets tight, they will expect more for less, and then things will have to change. At that point, there may be such an entrenched culture, it's impossible. No way to know.
I just know what I want for Christmas, and have a feeling I'm not going to get it...
I had no idea that the decompression I'd feel from leaving Finance and entering a pseudo-startup. I really didn't. In the beginning, I was thinking it'd be really nice. Sleep in… have lots of vacation… take your time learning new things - what's not to like about that? But that's not the whole picture, is it? It's never as easy as one quick look might suggest.
Today is another great example of some of the problems I'm facing in moving from where I was to where I am - and it's not about jerks, or mean people… it's about being in a Team, and having a Team member decide that he knows better than you - even though he's got far less experience than you.
I'm currently in a team that has lost three people - one to leaving the company, and two to other positions in the company. Unfortunately, two of those were really good guys, and I'm going to miss their approach to software development. As I told my manager yesterday in a 1:1, every project has "grunt work" to do - things that have to get done to move the project forward, and get deliverables out the door. It's called production for a reason.
Now I'm good at delivering code. Really good. Primarily because in Finance, you have to be, or you have to find another job. So I got good at it. That's not to say that's what I prefer to do, but I know that if the team doesn't deliver, it's not going to be long before they look to "lighten the load" of the team. I've no intention of that happening to me.
So I pick up the work if it's sitting there.
In a good team, others do this as well, so any one individual does a little, and the load is not dependent on one guy doing it all. But if you're in a group of people where they don't see that as "necessary", or they feel it's "beneath them", then you end up with a group that's very dysfunctional. In my case, that's where I am - doing about 90% of the code that's delivering.
This by itself, wouldn't be so bad. After all, I know what I'm doing, I trust that management sees the effort I'm putting in, and I'll get compensated for it. Not bad. But for the last several days, one of the guys in the group has been working on integrating the log files with an automated scraper - splunk, and while it was possible to build all the queries he needed with the tools at hand, and the log lines as they were, he decided that it was really time to make the logs less human readable, and more easily used by splunk.
This, I argued, wasn't a good idea. Log files are for people, not machines, and this was making them less readable, and that was bad. I tried to convince him that this was a bad direction, and he'd have none of it. No way I was going to convince him.
All this work - three days worth, because he wanted to gather a series of numbers in one query - not two.
Really!?
Two queries is "Bad"?
I had to walk away. I tried to talk him out of it. Just like I told my manager I'd try to do. But he was insistent. Totally unwilling to compromise. Yet I caught several errors he'd made because he wasn't paying attention to what he was doing.
I really hate this. I'd rather he just take time off and not be a problem as opposed to making things worse for me. And that's all he's really done. He's made the logs worse, and for no good reason whatsoever. None. The data was there, it's now there, but in a non-human-readable form, and he thinks that's "even"?
These kids, and that's all I can think it is… these kids have no respect for experience. None. But hey… why should they? They have done it all, right? They have built it, and it only took three days. Total crock.
We have been trying to move to JRuby 1.7.0, and running into a fair share of issues along the way. But still, we press on. Today we tried again, and failed, being stuck by another Dir.glob issue that has been a persistent little problem for us.
There are a lot of reasons we want to be on JRuby 1.7.0 - better socket implementation, better handling of exceptions up the stack, and better ruby 1.9 compatibility. All good things. But not being able to deploy in a jar has been a real pain. We need to be able to do this, and without it, we really can't move.
So we have been digging into the issues. Thankfully, for the latest one we have a work-around. It seems that JRuby 1.7.0 can handle Dir.glob, but only if the "path" does not start with jar:. Very interesting.
The work-around, then, is very simple:
def project_root @project_root ||= File.dirname(File.dirname(__FILE__)).gsub(/^jar:/, '') end
will get the root of the project in the filesystem or jar, and then if it starts with jar:, it'll strip it off. We use this for all file pathing, and we're good to go!
I've built a few rule-based systems in my time. Nothing like an Expert System, but enough to know that the business logic of most businesses is a complex thing, and care needs to be exercised in creating the rules, naming the rules, putting the rules into a cohesive system, and in general, making it work. What I'm a little surprised about today is that this isn't something that people seem to naturally pick up on.
I'm looking at code written by a smart guy. He's no dummy. He's got experience as well. Yet it seems that he's into making the worst named rules, and combining rules in ways that it's not clear what's being checked (asserted) in a rule, and why. The resulting combination of these rules is worse that just a series of if/then/else statements because it hides the things that are being checked behind very poorly named methods.
Yikes!
So today I did a lot of clean-up. The rules are clear, more reasonably named - when the functionality changed, and the layout is far better. I was pairing with someone and they weren't able to follow until I made it clear that there really was a "good way" to write these rules, and combining completely different rules into one wasn't really a "winning way".
It's not done, but it's getting closer, and I'm really surprised that this part of the codebase is so easily done. I had expected more, but again, it was blown out of proportion due to the things I'd heard from the people working on it.
Get good data. Understand it. Write good rules. Combine them. It's really not all that hard.
Today I had a really sad realization - there are a lot of lazy people in the world, and unfortunately, I have the pleasure of working with a few. These aren't the Code Monkeys I've written about several times - these are just really honest to goodness lazy people. Just looking to do the least work they have to do in order to get by. Fighting about it in meetings even. Amazing.
Case in point: Countries. We get the demand for things from a service that gives us location information as postal codes. In the US, that's great as a 5-digit zip code is just the right "size" for the localization of the demand. But in Canada, I found out that I should only be looking at the first three characters of the postal code. OK, I can do that, but the question then becomes: What country am I in?
I was thinking it would be a simple thing to have the service that generates this data to add that in. After all, it knows the postal code, so it's got to know the country - right? Well… as it turns out, it should, but it's written by some really bad coders, and it doesn't. And these bad coders are lazy to boot, and aren't interested in adding it.
OK, after about 30 sec of this "debate", I just said I'd do it. It took me about 30 mins to add this to my code, and now it's done. They later realized that they needed this as well, so they have hacked something together that I couldn't possibly care less about, but whatever. I have the country now.
I'm now able to map the postal codes right, but it's amazing how hard some people fight against making their code better - only to later realize that they should have made it better in the first place, and put another hack on a hack, etc.
Not me. Amazing people.
One of the problems of working with a lot of string data posing as enumerables, is that people are fuzzy logic kind of things, and the difference between "Wed to lead" and "Web to Lead" is totally lost on most people. But for the logic in the computer, they are apples and oranges. Unfortunately, we can't really turn them into enums, we have to leave them as strings. But the look-up tables have a certain case - defined by the Data Science guys, and that's something I had to work around.
Sadly, I couldn't just lower-case all the data as I read it in - that would adversely effect the look-up results. What I needed to do was to specifically lower-case the components of the key for the table, and leaving the rest of the data alone.
My goal in this little bit was to keep the knowledge of the key generation in the class doing the look-ups, and I got what I wanted. But I needed to make it a little smarter than it was originally. Not bad, and in the end, I don't have to worry about case of any of these "string enums".
There are times I'm amazed I keep my mouth shut. Today has given me several such times. Really. I'm grateful for this job, I truly am. I like that I'm learning ruby, and there's a lot of interesting work there, to be sure. But I'm working with the Code Monkeys, and it's really getting on my nerves today. Really.
One instance today was best typified by the mental picture of working around a bunch of eighth graders. Yup, kids. I enjoy chatting just fine. There's nothing wrong with learning more about your co-workers, but there's got to be a point where you turn around and get to work. After all… we're here because it's a job, not a clubhouse.
I don't know about the rest of the group, but I'd be home if it didn't matter to anyone else. I don't love the chair, or the desk, and the commute - well… don't even get me started. But it's OK - for a place to work.
I just seem to be in the vast minority some days. They want to play around, giggle, watch bouncing cats on a 40" plasma TV for fun - for far, far too long. Again, I like my job, but this is really getting annoying.
And if I say anything, I'm the kill joy, or the "old" person that doesn't understand the value of fun. After all, they'll get the work done - eventually.
Please… if you could get all the work done in the time you give it, think of what you could accomplish if you came in before 10:00! Or stayed after 4:00. Or didn't mess with the bouncing cats. It'd be like you had an entire day extra. Wow!
But that's only part of it… the other part is what I blame on the Agile approach, and it's focus on continual refactoring.
Again, don't get me wrong, I like that there's a focus on refactoring in the workflow - it allows you to go back when things have really changed, and fix them up the way you would have if you'd have known what the end-result was really going to be. But there should be a limit to this. Fixing broken, or badly laid out code is OK - if you're adding something, but if you're just looking around and just decide to change the code "because", then what you're really doing is wasting time. Lots of it.
You're also really running the risk of breaking things - unless you're really careful. I'm not convinced a single one of the Code Monkeys I work with is really careful. Smart - yes. Careful - not in the least.
There's no solution because it's all a matter of degree. I may think it's "too much", but that's an opinion, and as long as management is OK with the productivity, then there's nothing that's going to be done about it.