Clint Hill

Father, Son, Brother, Uncle
August 11, 2011

Nothing goes as planned

This last week has been great and exhausting. It has reminded me that nothing goes as planned.

When you’re a kid you plan on big things. You believe in big ideas. Some time later you give up on a few of those. Then as age creeps up on you, it starts to remove the gloss on those shiny plans you had.

It’s so obvious, and yet very hard to really accept. Plans are meant to be broken. You just can’t control life. Fate or higher power, call it whatever you want, just understand it’s not you.

Willie wrote once: “We are not in control. And that’s Ok.”

If you let plans slip, and allow it to be Ok, life is much easier to understand. Otherwise you can waste a lot of time being frustrated and confused.

This week a one or two things didn’t go as planned and it caused me a lot of stress and frustration. My patience got really thin a few times. But I can look back to this week and be happy, because while my plans changed my life didn’t.

And that’s Ok.

Leave a comment
July 30, 2011

Virtual Machine

Something that Oracle could do to truly revolutionize the Sun stack they bought: drop the “Java” from the Virtual Machine name. This would solidify the fact that you can use nearly any style language you wish, not just Java.

Twitter moving to the JVM more and more

The important part of this presentation is about the virtual machine and it’s performance/scaling. Not the language. In fact if he never mentioned languages at all the presentation is still valuable.

Leave a comment
July 23, 2011

Next Exciting Thought Exercise

At work and personally my next new shiny thing is the design of a framework for delivering JavaScript applications. It’s more than building modules, listing them in a gallery and then HOWTO documents, rather a top-to-bottom application UX delivery system.

This is more tricky than might be imagined. It’s a gallery of modules. It’s a development environment. It’s a hosting environment. It’s a core library. And not always in this order.

It’s exciting stuff to think about. And it’s really cool to think about doing it with JavaScript (client and server sides). A few things that cause concern are the definitions of things.

  • What is a module?
  • What is a component?
  • Is there a difference?
  • Or are components applications?
  • What does “development environment” mean?
  • Does hosting mean you get what you get or does it mean you can get what you want?

It’s answers to these questions that are critical in designing a system like this.

Fun stuff.

Leave a comment
July 17, 2011

1 week down

Finished a week of vacation. I accomplished most of what I wanted to do. Nothing for example was something I’d hoped to achieve. Check. There was a list of other things I’d hoped to do, and I did a little bit of each. I have 3 more days off. I think I’ll try to cram that list into these last few days.

Leave a comment
July 17, 2011

Sometimes it needs to be said

And this post says it so well: http://plope.com/smartest_guy_in_the_room

Leave a comment
July 7, 2011

Vacation

For the first time in a very long while, I have more than a 4 day weekend off of work. In fact I have more than a week. This weekend we’re going to Havasu to get out on the boat. After that however …

Just a quick list of hopeful things to do while I’m not working:

  • Get recpopulace out the door to beta
  • Finish porting of the Ruby Gem Citrus to JavaScript
  • Add 2 more projects to my Github account (citrus port and something else)
  • Spend a day with my sister and nephews and niece
  • Write a few more blog entries on something other than programming
  • Get A/C in the garage – money permitting

I’ll obviously spend a lot of time with the girls. And I’ll have the obvious chores around the house. And now that I’ve created a list I feel like I won’t have enough time.

Geez.

:)

Leave a comment
July 4, 2011

Software Abstractions

Abstrations are hard to debug, require a learning curve of 2x the original problem and are rarely complete.

chrisjsmith

This was part of a comment left on Hacker News to a post about Coffeekup. Coffeekup is a CoffeeScript abstraction over HTML. Just like HAML. The beauty of the comment is how concise it is to the real problem with abstractions.

Abstractions are key to developing good software libraries. They are shortcuts for what otherwise might be lines and lines of code. The jQuery JavaScript library is a great abstraction over JavaScript. It takes what would be tons of “document.querySelectorAll(‘selector’)” kinds of code and distills it down to “$(‘selector’)”. This is a good abstraction because it’s JavaScript over JavaScript.

And in many cases developers will build libraries of abstractions in the name of “platform”. That is to say that you can create a platform for building software based on a frameworks full of these kinds of abstractions. An example might be to use Google Web Toolkit to build web pages which would allow you to write “everything” in Java, and compile it down to JavaScript.

The quote points out why this is not always the best solution. The reason is simple: It’s Java over JavaScript. Right away the learning curve is 2x the original problem. What you may not be familiar with in JavaScript may only loosely compare in Java due to differences in language. It is much harder to debug – regardless of the debugger provided – because of the native differences in runtime for each language. More importantly, is that it requires more lines of code to achieve the same effect. What is typically a few lines in JavaScript inevitably turns into tens to hundreds of lines of code in Java. The compilation process is so effective that the hundreds of lines of code in Java turns back into those few lines of JavaScript. Which to me argues the benefit. Is there one?

 

 

 

 

 

Leave a comment
July 4, 2011

Educate the junior

One of the bigger tasks I have at work is to create software libraries and systems that others will reuse. The hardest part of that task is to create something that will prevent common mistakes and/or prevent a developer from implementing non-standard software. It’s my opinion there is a missed opportunity to educate the users.

There’s an old joke about the C programming language that says it allows you to shoot yourself in the foot. And mostly that is a fair statement to make, with one caveat. The caveat is: if you don’t know what you’re doing, you will shoot yourself in the foot. And this isn’t a software programming thing. You can say this about a lot of things. But with software it just so happens that as a lesser experienced developer you are capable of creating and doing quite a number of things with the power to shoot yourself in the foot and not know it until there’s blood everywhere.

Creating libraries and systems that can be reused and won’t allow the user to do something bad (knowingly or not) is really hard to do. How do you write a recipe for a casserole that prevents the cook from burning it? Or how do you give someone directions to your house that prevents them from missing the street sign? Now imagine writing a recipe for a casserole that allows someone else to write their own recipe for a casserole? That’s what a software library should do when it’s really good.

It’s difficult if the target audience of the library or system is what some call “junior”. This is to say they have less experience or don’t have the skill set utilized in the library. A Java developer using a JavaScript library for example. Juniors may barely have experience with JavaScript but now be tasked with using this library. Obviously a good library will help them do things with the limited experience. But that doesn’t help them with the things outside of the library. And it certainly won’t prevent all the mistakes that can be made.

I was reminded of this today as I was putting together a desk I bought from Target. The instructions were written with a tone of “don’t worry we’ve written instructions to all but do the work for you.” Pretty bold claims. Then I imagined myself without the experience I have with regular tools. What if I wasn’t sure what a Phillips screwdriver was? And what if I didn’t know the difference between that and a flat-head? Sure there is a picture showing both, but the screws provided accept both. Hmmm. One is certainly better than the other for this setup, but what if I didn’t know better. The problem is the instructions gave me just enough to get the work done, but not prevent blood. What was missing was experience or an education of how to use the tools and in what context they’re suited best.

It’s my opinion that what is really missing in a lot of software development is education. Not the school kind of education, but the hands-on side-by-side kind. Giving presentations, pair programming and one-on-one work are a few ways to help educate. In most cases it just takes time, sitting with a junior and showing them. Write some code. Make some changes. Explain. Rinse and repeat. It’s quite alright to develop libraries and systems that make mistakes go away. But it would be even better to educate. With an educated development crew, the libraries can focus on doing cool stuff and drop the need for all the preventative stuff. Teach the developer to prevent mistakes themselves.

Educating the junior isn’t easy. In fact it’s down-right hard. Each developer learns differently and at varying pace. But if taught there is more to gain than what a perfectly written library could ever achieve. In fact that is the crux of my thought. More juniors turned into seniors is always a better investment. A library may prevent the majority of mistakes but it will always be just a library. A developer who is educated will always be capable of producing more.

 

 

Leave a comment
June 25, 2011

Decisions, decisions

There are decisions to make almost everyday where I work. Software development is literally chock full of decisions. Who makes the decisions is most often is not the problem. Rather the lack of someone making a decision is most often the problem.

I work in a company that is pretty typical with corporate hierarchal authority. There are your C level people, VPs and all kinds of middle management. Mostly it makes sense who is who.

It’s only confusing however at the lower levels. The levels where there isn’t a hierarchy. In most cases the upper levels of authority like to empower the lower levels (they say they do at least). That word empowerment is funny. By definition it means to relinquish power to someone else. All well and good. But does that mean that every subordinate has authority? And what are the boundaries to that empowerment? When everyone has the power to make a decision, who gets the last one? There has to be a final decision right?

In software development some would call this “design by committee” and generally it’s with a bad connotation. The dislike for committees is likely due to the belief that there ought to be a final decision in software design. Even if that decision is temporary or up for change later, it’s kind of final and work can move forward. Otherwise if there isn’t a final decision work doesn’t progress. Instead it’s debated and deliberated ad nauseam.

There are good reasons to have committees. There are also very good reasons to debate decisions. Some decisions are long lasting and making the wrong call could effect a large number of people in a harmful way. These kinds of decisions need thorough analysis. But those kinds of decisions are few and far between. Really far between. If decisions are rated on a scale of 1-5 with 5 being “really impacting” and 1 being “harmless to all” I would guess that 90% of all decisions are below a 3. Committees should be for the 4 & 5 decisions. In all other cases there should be only one person making the decisions. Leave the debating to the important stuff. One person should make a call on the rest allowing everyone to move forward.

The trouble is when there isn’t a hierarchy at the levels where 90% of decisions exist. Those decisions are then left for the upper levels of authority to make. And then the volley starts. Upper levels say “go ahead with whatever you think best” and then lower levels say “we’ve come up with a bunch of options – which one do you want” and then back and forth. Empowerment is great, but it’s not always useful for a group or committee.

For me personally, it’s frustrating when groups don’t have a single lead, decision maker or tie-breaker. It’s really aggravating in some cases. It’s pretty often that I really want to make the call, and most often I do voice my opinion. Sometimes I get it right and others will follow. Sometimes I get it wrong and someone else gets it right. Generally I’m Ok with this (but often I think my decision is better for whatever ego driven reason). I’m sure many others feel this same way, it’s pretty natural I’d guess. And I’m sure there are others that don’t really care to make a decision, rather they’d prefer to be told. This is fine too, in fact it would argue my point that each level of organization ought to have one decision maker. Consider what would happen to a team that is full of people not interested in making a decision but have been empowered to do so?

Decision making occurs everyday. There ought to be someone designated to do just that at all levels of an organization. At least someone designated as a tie-breaker.

 

Leave a comment
April 30, 2011

Working on large code bases for large web sites

I watched a presentation today from a Facebook engineer that ended with valuable information. Generally an interesting presentation about the ups and downs they faced with their code. Surprisingly blunt about technology choices as well.

Around 46:40 he talks about Practical Advice. This is the part that caught me.

Evolution of Code Design at Facebook

Don’t Branch

This I wholeheartedly agree with. In my opinion when you decide to branch code to do any form of refactoring you immediately create new problems for yourself. The first problem is “when” to merge back into trunk. Do you merge after everything in your branch is perfectly tested? Or do you wait till both your branch and trunk are perfectly tested? If there was bug fixing going on in trunk while you’re branched testing has to occur for both – but which version do you accept – the trunk or the branch?

 

The second problem is what to do with conflicts of the merge that exist on the edges of your changes. Do you refactor the trunk just enough to fit the edges? Or do you change your branch to accomodate those edges in trunk? Do you allow these edges to change your design in the branch? And how much time do you spend doing this – just enough to mash it together or enough to have long lasting durability?

The easy answer in my opinion is stay in trunk. Get over your fear of “what happens when my code change breaks the rest of it”. That’s what revisions are for and if you’re smart with your unit testing and judicious with your commits you should never run into broken builds. Most often in my experience developers who immediately reach for a branch are developers who don’t have sufficient tests for their code (me included).

Confession: I am often saying “I’ve never been mad at myself for branching”. And the reason I say this is because I work(ed) in environments where trunk is abused and brittle. Or often too many developers are making too many changes at once. I say it with the sentiment that I want to branch and not have to worry about what the flaky trunk might do. And when I merge, my branch is the winner in all cases. But always (and I mean always) this causes me to have to make code changes in trunk after I merge. Always. And usually afterwards I say “should’ve stayed in trunk”.

Take advantage of product churn

Ah. I love this one. It’s so obvious but yet so hard to really get. In most large websites there is a product group of folks who decide the features. They change their minds a lot. And that is exactly their job. So when they do, why would you stick with a design and/or architecture that solved the previous problem. Or why would you try to design something so long lasting? Take advantage of a clean slate.

 

There are plenty of arguments to be made for architecting solid systems that can support change. My point is don’t get bound up in architecture decisions so tightly that when change does occur you become adverse. Be flexible and open to the idea that product teams may come to you and say feature X is the next best thing. And that feature may create a ripple in your architecture. If it does, roll with it and re-architect.

It’s my experience that the reason why you get this adversity to re-architect is generally due to the size of the development staff. When you’re dealing with a large staff it is nearly impossible to make quick changes to the architecture. Every developer has to be at a minimum aware of the change, and most of them often implement the change. And when the number of developers is high, the slower the change can occur.

Focus on usability

This is targeted at developer APIs and frameworks, and I do agree but I’m less adamant about it. Or should I say that my version of adoption isn’t so much about winning hearts and minds as much as working with people willing to adopt. And there is a big difference. Top down mandates are a result of working with a development staff that is just not very good with adoption. Organic adoption happens with a certain chemistry and culture. Develop those things first then adoption comes with it. This is a tricky bit to do. And in my experience top down mandates have always been easier (especially in larger development groups). I wish it were different, and I realize my personal style is much different than others.

 

It all depends at which level you are. For instance I hate being told “which way to do it”. But if I’ve come up with a better way I wish I could give the top down mandate. Organic adoption is always better, but it just doesn’t always work.

Generally I agree with all of these kinds of advice. But admittedly I’m more liberal in my approach to design/architecture/coding. I find myself more open than others to change and especially using yet unfamiliar technology. I dislike rigor and unnecessary structure or process, but I’m not opposed to smart and reasonable standards. But the advice given was sound in my opinion.

Leave a comment
Follow

Get every new post delivered to your Inbox.