The hard drive saga gets worse….

So that hard drive swap? The story got worse.

After the long weekend of swapping and getting back up to speed, I finally go back to work. Close the lid on the MacBookPro, lift it to put it into my bag… and there’s this buzzing noise coming from the hard drive. It sounded like a lightsaber (best way to describe it).

That can’t be good.

I contacted Other World Computing about it. It only makes the sound when on… doesn’t have to be going to sleep, could be lid open and in the middle of doing whatever, pick up the machine and tilt it (not even a quick tilt, just gently) and noise. So it’s not say a loose bracket or something. They opt to send me a replacement. I got the replacement just before this past weekend, and just time.

See, all the week while I had the new drive in, I had strange crashes. Some background daemon would crash, or Xcode would crash in a non-normal way (yeah, Xcode 5.0.2 crashes on me, but the crashes seem to be fairly deterministic and reliable — these new crashes were out of character).

Made worse? All day Friday while at home (the great Austin Ice Storm of 2014!) I kernel panicked 3 times. Well, more than that, but after the 3rd one I figured it was time to stop work for the day and investigate. All my crashing and panicking was coming out of processes like mds and backupd, which starts to point to disk i/o. Hrm.

So I swap in the new drive (so we have “original drive”, “replacement drive 1” and now “replacement drive 2”. I put replacement 2 in, and start the process again of restoring things. Hrm. Long story short, first restore attempts fails for some unknown reason. Try again, and it appears to have succeeded but didn’t, because reboot and while booting it panics again (couldn’t find ‘init’. That’s bad). So again I go around and around. Yeah, it starts to panic again.

And I tried tilting the machine. Sure enough, replacement 2 makes the same vibration lightsaber noise.

Well crap.

It’s unlikely to have 2 faulty drives in a row, possible, but unlikely. What gives?

I did a bunch more experimentation. After talking it over with my buddy W, it came down to a simple thing: time vs. money. To try to further diagnose this problem would require a lot of time, perhaps a week or two without the machine. I cannot afford that. If it was just for email and Facebook, whatever. But as a developer, the machine is vital to my daily existence. Time is more critical here.


I am now the proud owner of a MacBookPro11,3 — the 15″ retina model. 🙂 And the big model too, because these machines can’t really be modified or upgraded after the fact, and 16 GB of RAM and 1 TB drive space matters given what I do in a day.

No, I’m not happy to have suddenly dropped 3-grand (and yes, I got AppleCare — always do), but I’m thankful that I could.

So I’ve used Migration Assistant and things seem to be getting back to normal.

As for the other machine….

While doing some of this restore work, I had put their “replacement 1” into an external case (see their DIY upgrade kit). On a whim I tried it… I just tilted the naked drive. Sure enough, it vibrated. I’ve been in communication with OWC’s tech support, and just sent them a follow-up with a little video of the vibration noise. We’ll see what they say.

I was convinced the old MacBookPro was dying a hardware death somewhere, but now I’m not so convinced. Nothing I can do about it now… I guess it just means the kids get a nice MacBookPro for school. But we’ll see how everything shakes out in the end.

The story continues…. but I just hope that I’m nearing the end of it, at least the major headache portions.

PanemQuotidianum 1.0 is now available

December 13, 2013 (Austin, Texas) – Hsoi Enterprises LLC announces the release of PanemQuotidianum 1.0 – an iOS (iPhone/iPad) app bringing you Daily Bread for your Daily Life.

PanemQuotidianum is “daily bread” for your Catholic life.

Every day you can wake up (or go to sleep) with a bite of spiritual bread to nourish your soul. It’s light and simple, but filling and satisfying.

Simply set when you’d like to receive your panem, and you’re done. Each day at your set time, a notification will post. Respond to that notification to view that day’s posting.

PanemQuotidianum represents a labor of love, and the first collaborative effort to grow Hsoi Enterprises LLC as family business. Thank you for supporting our efforts.

PanemQuotidianum is available now in the Apple App Store for $1.99. A portion of the proceeds will be donated to Catholic charities.

PanemQuotidianum – Your Daily Bread for your Daily Life.™

kwikkEmail 1.0.3 live in the App Store

I occupy my time with writing and releasing software. The latest — kwikkEmail 1.0.3 — just went live in the App Store.

Thank you for your support.

More stuff for learning to program

A few days ago I wrote about Scratch, a nifty way to help my kids learn how to program.

I forgot a couple other things I found.

Stencyl. This looks neat. It I haven’t used it, but from what I read it looks like it follows the same sort of drag and drop “block” programming structure and logic that Scratch does. But it can be used to actually make iOS and Android products that you can actually ship and sell. So maybe after Scratch, this would be something to try. It would take the knowledge they had before, but now they have to actually make something polished and ship. A good “bridge” between the two worlds, so to speak.

There’s also GameSalad, which is made right here in Austin.

I still would want them to learn “real” languages (e.g. Objective-C, C++, Python, Ruby, Java, JavaScript, and maybe even new funky languages like Scala). Who knows. I think tho it needs to start with a desire to do it, and to really gain a love for it. If things like Scratch or Stencyl take off for them, then we’ll go there.

Who knows. 🙂


Learning to program

Youngest walks up to me about a month ago and asks how you program (write software for computers).

Oh joy! 🙂

Now I’ve talked about learning to program before and even a second time. I always come back to Karel the Robot as a great way to learn how to program. Why? Because you get to learn the constructs of programming without being burden by the constructs of programming. You can learn about loops and conditionals and variables and logic and flow, but you don’t have to spend 3 hours debugging a problem to find out it was because you misplaced a comma. And it doesn’t matter if you really do anything useful or not at this stage, in terms of gaining some employable skill (no job listings for Karel knowledge); once you learn how to program, then languages are just languages and toolsets are just toolsets.

Back when I looked at the LEGO Heavy Weapons book, No Starch Press offered other books to me to review. I asked about the Python for Kids book because it looked like it might be a great way to start the kids into programming. They sent me a copy, but I have yet to go through it. Mostly inertia on my part. Daughter asked me about it, but just a passing interest. And I must admit, while I think the book is well done for what it is, I still think it’s not a perfect start because there’s issues of language that get in the way. You have to get bogged down by syntax of Python. It’s not horrible of course, but I know things can be simpler. I think this book would make a good “phase 2”.

When Youngest asked me again, I went looking around. I found Scratch from MIT.

I think I’ve found what I’ve been looking for.

Youngest and I played around with this for a bit, doing the tutorial. I saw how Scratch gave you all the language, all the logic, even some advanced things like variables, lists, and inter-object messaging. It’s actually pretty cool. I liked the way you just drag and drop to make logic go. It also is able to give you direct feedback, which I think is good for capturing a child’s interest in the topic. I encouraged Youngest to “just try it”. What would happen if? Just try it and see! The environment is very forgiving, but even still, you can make mistakes and have to learn to debug.

I also really dig that all Scratch projects are “open source”. You can look at what others have done, and then you can look at the “source code” to see how they did it. I was able to find a simple game on the site, then show everyone how they made it happen and how neat that was.

So I’m working on this with Youngest. I told him a simple project he could start with would be reinventing comics. We all love Pearls Before Swine and I told him he could start by taking a simple Pearls comic (maybe just Pig and Rat talking to each other) and recreating it in Scratch. It’s a simple project, simple goals, but challenging enough to get your feet wet with.

And we joke… with Youngest programming… Daughter creating artwork and music… Oldest creating artwork, music, and overall design work… they all like to make movies, do voice work. Oh geez… I’ve got an in-house dev shop now!

Man, I wonder how far this ball will roll. 🙂

My evolution of style

I don’t write about programming as much as I do other topics, but if you look at number of hours spent on something in a day, programming comes out at the top of my list. My day job has me writing iPhone apps, and my night job does too.

One topic that is a source of endless discussion amongst programmers is that of programming style. Just like you can have MLA style, the AP Stylebook, and the like, so too do programmers have a style to their writing. What we have to realize is once the code is written, it will forever be maintained — which requires reading it. Thus, style is important to aid readability, and no one questions that.

But everyone wants to question what the style should be.

And of course, my way is the right way.


I’ve been doing this long enough (I’m not a graybeard just because my beard is turning gray) to know there is no One True Way®. As long as you have some sort of consistent style and you produce readable code that’s appropriate for the context (because yes, certain programming languages and toolsets will bring about different styles), that’s essentially what matters. Yet, we still have people persisting their style is the one way that all code that a project involves must be written that way. Why? To what meaningful end does this address?

Style guides that merely propose cosmetic changes are useless and ego-driven, IMHO. But when the style has purpose and actually works to improve the code itself, has solid reasons behind the choices? That’s different.

When I started out, I didn’t have style. No one does. You eventually pick it up as you write more code. My first formal endeavor was working as a developer of a then-popular C++ Mac framework called PowerPlant. When I asked about coding style, the Grew Dow (creator) said “mine”. 🙂  Basically, PowerPlant was Greg’s baby and if I was going to write code for it to be included in the official distribution of it, I had to make my code look like his. This was a lot more than just where the curly braces went, but a lot of other form and function choices too. IIRC, Greg taught me this:

bool x = false;
if (SomeTest()) {
    x = true;
return x;

Compare to this:

bool x;
if (SomeTest()) {
    x = true;
else {
    x = false;
return x;

The first is more readable, more compact code, and generates better code too. The end result is the same. Go with the first.

This was a matter of style, but it produced better code.


Over the years my style has changed. In fact, one change happened within the past year, and I’m pretty happy with it. It concerns everyone’s favorite debate: curly braces!

I started out with:

if (foo)

Because whitespace is good. Thus why I didn’t like:

if (foo) {
} else {

Because while compact and nice on screen space, it wasn’t as good on the eye because the “else” wasn’t in a column with the “if” (for visual scanning, since we sometimes will process the code in “blurry” visual chunks, not necessarily processing the actual code), and depending upon the complexity of the code, readability wasn’t always best.

I flipped flopped around for a while on this, especially since Cocoa coding brings a lot of its own conventions to the mix, which for the most part are well-worth adopting especially since some are imposed on you in order to make things work. My current style?

if (foo) {
else {

I find this works better because there’s better visual chunking of the data, better organization. It helps to keep the code compact, doesn’t waste too much space, but yet still keeps some whitespace around. It’s hard to get a feel for this style in small code snippets, but when you use it all day in various bits of code, it gets vetted and I’ve found this works quite well.

Of course, do-while is still potentially weird. 🙂


I still debate this one.

I think it’s clearer to say:

NSString* string;


NSString *string;

Because to me, it’s making the type clear. That is, this is an NSString pointer. It makes sense too when you look at function/method arguments, be it C, C++, or Objective-C, because you declare return types as such and arguments do not always need a variable name, just the type. Thus:

- (NSString*)foo:(NSString*)s;

is legit and correct.

The only place I find this breaks down is if you wish to declare variables with a comma:

NSString* string1, *string2;

So you have to do that. But I also think it’s generally bad-form to declare with a comma, especially since it gets really messy looking with initialization, and in general you should initialize your variables (at declaration time).


Another style change I made was spaces. Or rather, spaces vs. tabs.

I always used tabs. I preferred tabs. It made editing a lot easier. I did set my tabs to 4 spaces, but I still used tabs. I hated people that used spaces instead of tabs because it made editing hard.

When I came to my current day job, the server side was being done with Ruby (and Ruby on Rails). Those guys like spaces, and using 2 spaces per tab. And so, the clash began. The then-lead on things asked us to just switch to using spaces instead of tabs (tho we could stay at 4 per), and I just gave in because it was easier. Because that really was the problem: mixed setups.

I recall back at Metrowerks, most people used tabs with 4 spaces per tabs. I think one guy liked 8 spaces per tab, and then there was another guy that liked 3. Yes… 3. That made his code really weird to look at when you opened it up in your editor, because things lined up really wonky. And so problems arose when you couldn’t really read someone’s code (back to that readability thing), and it was made worse when people with different tab settings edited the same file.

Basically, it became a huge mess once you left the ability to have a homogeneous environment and complete control over it.

Using spaces instead of tabs fixes most of that. You can’t fix if people use different substitution values (e.g. 2 per vs. 4 per), but you will still end up with consistent-looking code when you open it up in a different editor, because a space is a space.

But this made me realize why I resisted for so long.


Your choice of editor tool matters, and affects your style.

For example, with the spaces vs. tabs situation, I hated using spaces because if I hit tab too many times, now I have to backspace a LOT in order to delete all those spaces, instead of just a couple backspaces to undo what I did. Typing out code isn’t like typing out a letter or a blog post, because a lot of keystrokes can be for formatting and navigation around the code. So now to have to do all this extra work, it adds up in a day.

But now, I have an editor that is smart(er) about this situation. So if I have tabs actually be 4 spaces, I hit tab, the cursor “tabs in” but really 4 spaces were entered. And if I mess up and press delete, it will “untab” and delete the 4 spaces. Having an editor that is smart about such things really goes a long way, not just towards helping you write code, but helping you manage these sorts of style choices.

I would also add that the growth of screen size and resolution has helped a great deal. We aren’t using VT100 terminals limited to 24 rows and 80 columns, yet some people still cling to that standard. Why? Even our tiny mobile devices aren’t so limited. Granted, if you are in a particular environment that requires such constraints that’s one thing. But I primarily work on a 17″ MacBook Pro with a 1920×1200 screen; I used to work with 2-3 total monitors. We have the space, we should use it. Our eyes like to see a wide horizontal plane (thus why TV’s are widescreen and movies are wider not taller). Use that.

Thankfully Xcode is really getting better about these things. It’s taken a while, and it was really important for Xcode to be an awesome editor because the 3rd party editor road and integration/support was just not happening.

One thing that I’ve also given into is code completion. I didn’t like it because hey… what’s so hard about typing things out? Well, with some iOS/Cocoa API’s, it’s quite hard because the names can be VERY long and difficult to remember. So code completion has worked out to be a quite useful thing. But with that comes some imposition of style because someone had to decide how to insert that text. Xcode also allows some level of syntax-aware editing, where it can do things like auto-indent and the like. You have some control to pick and choose, and really once you tweak things to your liking the automation is nice. But again, there’s some level of imposition of style here that you cannot get around, especially if your choice isn’t represented in Xcode’s options.

Point is, your choice of editor can be a bane and a boon. In general, they should be there to help you write better code, more efficiently. But while doing so, it may require you to make some choices in your coding style. Don’t fight it, go with it. You might find some benefit to that stylistic approach. It’s worth the time to experiment with it, especially if it winds up improving your point of view, improving your code, or just giving you solid reasons and experience behind your rejection of that approach.

Editor Customization

And so, if the editor app matters, hopefully you can customize it to suit your needs.

I can touch-type, and I find it much faster to use keystrokes than to stop and utilize the mouse – I don’t have to (re)move (then replace) my hands. I know many people that use laptops as their primary computer, but hook up external keyboards and mice to it. To an extent I understand this, but again it’s about having good tools. If you use the keypad a fair deal, the loss of it on a laptop keyboard is a detriment. If your laptop’s pointing device merely moves the cursor on screen, an external mouse may work better for you (especially that scrollwheel). But I’m happy my MacBook Pro’s trackpad supports gestures, and I use them constantly to allow me to more easily move about not just my source code, but my whole computer. Taking advantage of Spaces (well, Mission Control – having multiple Desktops) is a big boon because I can put my communication (email, web, IM/chat) on one Desktop, Xcode on another, etc.. Gestures are useful.

Granted, I cannot customize the gestures so much as I can customize keyboard keystrokes. But thankfully I can and use that to help me efficient access the commands I use most.

Another customization has been the use of editor color. I like the solarized project for how it effectively syntax colors, but also is very easy on the eyes. Quite important when you’re staring at the screen all day.

Plugins are useful too, and this comes more directly back to my discussion of style. I found a useful plugin, VVDocumenter-Xcode. This is a simple Xcode plugin that with a simple keystroke inserts basic formatting for appledoc-style documentation (and I’m going to modify this for Xcode 5). Just like the endless debate about comments in code, there’s debate about how much documentation one should have. I am not always good about complete documentation (you get into a groove with coding, documentation becomes a secondary concern, then you don’t have time to go back), but a plugin like this makes it much easier. Furthermore, with some advances in Xcode 5, there’s even more incentive to document in a particular structure. I cannot comment further yet as Xcode 5 is presently under NDA. Nevertheless, documentation and documentation style is an important consideration in your coding practice. Because again, style is about making readable and maintainable code.

The Style of No-Style

Styles tend to not only separate men – because they have their own doctrines and then the doctrine became the gospel truth that you cannot change. But if you do not have a style, if you just say: Well, here I am as a human being, how can I express myself totally and completely? Now, that way you won’t create a style, because style is a crystallization. That way, it’s a process of continuing growth.

– Bruce Lee

My style is my style. It is what allows me to most effectively communicate. It is what allows me to best express my thoughts, in code, in implementing a solution to a problem. For me to use your style would get in the way of my effective communication, so why should I do it?

I look at modern programming teams. Typically they are comprised of many people of different backgrounds, and often these days, ethnicities and origins. I say this because not everyone on the team might speak English the same as you or as well as you. Joe speaks with a southern accent and phrasing, and Young-soo speaks more in Engrish. If we forced “1 true way” of speaking upon Joe and Young-soo, if we made them all speak in British English (colloquialisms and all), how effective would that be for the team? We’d never think of doing such a thing, yet it’s precisely what we do when we impose “1 true style” of coding upon a whole team. Does that really lend to effective coding? to effective communication and expression?

Or can we accept that there’s at least enough of a style, enough of a standard in place that allows us to get the job done with each member expressing themselves as best as they can? Oh sure, if we find ways to help improve our communication, we should improve (e.g. allow your style to evolve). Just keep in mind what a coding style is to be for, and work towards enabling the team to effectively express themselves and write successful code.

If you have no particular style, if you need to find some way to improve the team’s workings, adopting style guides such as the NYTimes Objective-C Style Guide can be useful. Even if you don’t need such a guide, consider what the guide has because there may be a new twist or technique that allows you to improve your code. For example, reading that guide reminded me about Xcode’s expanded support for literals and how BOOL isn’t quite what you think. If we can write better code, if we can more fully express ourselves, style is a benefit. Just keep it in such perspective.

WordPress fail

I downloaded the WordPress iOS app update.

Installed. Oh hey, this “Notifications” thing is new. Let’s go see.



Relaunch the app.

Oh cool. They have some mechanism that autodetects the crash and looks like it can send the crash report…. oh the app just crashed again.


And now it’s caught in an endless crash loop. Launch app, crash detector comes up for a couple seconds, then the app crashes. Lather, rinse, repeat.

Just awesome. 🙂


Smart guns? Dumb idea.

So, Jeremy Shane thinks the solution to the problem is to “make guns smart”: (h/t Shawn)

While the debate rages on, it’s worth thinking out of the box for a moment. What if we could design guns to be smarter and safer — with hardware and software? The right technology could neutralize the killing capability of an assault weapon, even in a madman’s hands.

After reading Mr. Shane’s article, I’m not sure how much he knows about guns or software, but it comes off like he doesn’t know much. I’m a firearms instructor and have been a software developer for over 20 years, so I know a few things about both realms. Given that, while I applaud Mr. Shane’s imagination, I can say his ideas are best left to the imagination, as realization of them will not lead to the end goals he desires.

The root of the problem is that guns are “dumb.” Pull the trigger and they discharge bullets mindlessly, regardless of who is doing the aiming or where they are aimed. Guns should “know” not to fire in schools, churches, hospitals or malls. They should sense when they are being aimed at a child, or at a person when no other guns are nearby.

Most useful tools are dumb. We don’t have “smart” hammers, smart screwdrivers, smart knives, smart binoculars, smart blenders, smart cars… well, granted some things are starting to try to move that way, but most things understand that those “smart” devices can really only operate in dumb environments. No computer can process information as fast and as well as the human brain, can make the “instant” decisions that sometimes are necessary. The “touchier” the environment, the more humans are still needed. Even with all the safety technology being brought into cars, we still haven’t eliminated the driver because there are just some things the car cannot do and only a human can.

Should guns “know” not to fire into schools or churches or hospitals or malls? I don’t know… what if there’s an active shooter in a school or church or mall (since that’s where most such events have happened)? Wouldn’t you want the good guys to have guns that can work in those environments?

They should sense being aimed at a child. How would that work? Define “child”, as some sort of optical device would perceive them? I mean, I know some young teenagers that are larger than adults, some adults that cast child-like silhouettes. Mr. Shane also says “Sensory data can be used by built-in software to disable firing if the gun is pointed at a child or someone holding a child.”. Or someone holding a child… So a gun shouldn’t be functional if pointed at the person kidnapping your child?

You see, these are subjective decisions. How exactly can software make the sort of decision necessary? And even if it can, it takes time, time that may not be present as a horrible event is unfolding.

If you wish to have software attempt to make these subjective decisions, we have to remember that software is imperfect. It’s written by humans — who are imperfect — and software has bugs. It may not be robust enough. It may not be sound enough. It may hold bias of the programmer. I mean, for all my care and concern at writing bug-free code in my decades of programming, it’s impossible to write bug-free code. Do you want YOUR bug to be responsible for someone’s death? That it might not fire when you need it to fire, or that it fires when you don’t want it to fire? And then, who bears the responsibility for such a mistake?

Couldn’t gun software be hacked? Perhaps, but the risk can be reduced by open-sourcing code, requiring software patch downloads, and notifying gun makers or law enforcement if software is disabled. Open-sourcing code is not foolproof, but it will build a community of lawful gun owners and code writers who value safety and Second Amendment rights. Enabling two-way communication between guns and their original makers will help guns to be tracked beyond the initial sale, putting greater long-term responsibility on gun makers.

Nice thought, but open source code is still not bug-free and still can have horrible things happen. And there’s nothing here to address “software hacks”, but boy… what about viruses? what about social engineering? hardware hacks (I mean, why not just disassemble the gun and disable or replace the mechanism)? It’s not like DRM has really stopped piracy. It’s not like iPhone’s don’t keep getting jailbroken. There’s so many other things that can happen and be made to go wrong, to bypass, or to even force malfunctions. Wouldn’t it just be dandy if some virus was let loose that caused all these guns to rapidly empty their magazines at some coordinated time of day… all around the world… *shudder*.

There have been groups that have attempted such “smart guns”, and all have failed. Not only because the system itself doesn’t really work out, but because no one is willing to buy said “smart” systems. There’s no police nor military group that would want to buy such a thing, because they operate in environments where you may need to shoot multiple rounds in a school at a person holding a child. They understand these “smart” systems are anything but, and are too risky and prone to failure, and not worth risking their lives over. So you may say, only sell “dumb guns” to police and military. Realize then that still means such guns would be in circulation, and thus bad people will still get a hold of them. Of course, if you know anything about weapons fashioned and found in prisons, bad people will get weapons without your “smart restrictions” if they really want them. Even if somehow that’s all there is, there are going to be other “dumb” ways to cause mass destruction; look at Timothy McVeigh. So all these “smart” weapons would do is abridge and hamper law-abiding good citizens. Why do you want to do that?

You see, a well-made gun is actually a very simple mechanical system; it’s a simple machine. Once you start to add all of these things on it, start trying to add GPS, sensory data, target discernment, you start making for a massively complex system. And with any complex system, it starts to become… well… complex. Difficult. And prone to mistakes.

If truly you value life, should it be held to a system that can be massively complex and prone to mistakes? For all your attribution to car technology, Mr. Shane, consider how many recalls happen every year. A car is a massively complex system, and while it may work most of the time, you know all too well that cars break down and fail us. Thankfully most of the time car breakdowns don’t have life hanging in the balance. But when good guys need their guns, for certain lives are hanging in the balance — do we really want the risk of breakdown when preserving life is most critical?

It’s a nice thought, but technology cannot save us. Fixing our cultural and social norms and behaviors is at the root of solving this problem.

A year since we’ve said goodbye

A friend pointed me to the Apple website, because 1 year ago today, Steve Jobs passed away. Apple changed their home page today to post a video (linked here, but no idea how long this link will remain, or if it’ll move to a more permanent home eventually), a tribute and remembrance of Steve Jobs.

Yeah… it choked me up a bit.

I didn’t know Steve at all, but my first computer was an Apple //e, and the day I saw a Mac… it changed my life. I’ve spent over 20 years writing Mac and now iOS software professionally, so yeah… Apple has a place in my life.

At the end of the video you hear Steve say:

It’s technology married with liberal arts, married with the humanities, that yields us the result that makes our heart sing.

That’s what people tend to not get.

Sure, iPhone is behind Android in a lot of respects. In fact, in many respects Mac has been behind the PC/Windows. But in many other respects, Apple has completely lead the way in both the desktop Mac and mobile iPhone world (and let’s not forget the music iPod world either). And the biggest leader is Apple make products people want to have, that people yearn to have. Who lines up for the midnight release of any product? What other customers find opening the box to be a religious experience? that a product, a service, a brand creates such intense devotion… to plastic and silicon?

There’s an aesthetic.

I see Android devices all day at my day job, and I just can’t like them. Same with Windows vs. Mac. Oh sure, I can totally appreciate the technology going into them, both the hardware and the OS. I think there’s actually a lot of cool stuff about Android as an OS. But it just doesn’t sing to me. It doesn’t move me. I don’t look at it as a joy that I like to look at for hours every day, which is what I have to do. If I have to stare at something for a long time, I like it to be pleasing to the eyes (like my wife), and somehow stir my soul (like my wife).

To some people, they don’t care. These things don’t matter to them. And that’s OK. To some it’s pure utilitarian, or they don’t know any different or don’t care. And that’s fine. That’s them.


Well, speaking of Steve… if you consider his background with typography and how that influenced the development of Mac. Just the other day I read about a new programmer’s font, the article mentioned a few, I downloaded and tried them out, and settled on Source Code Pro. It’s a beautiful font. It’s a lot nicer on the eyes, and when you’re staring at code all day long well… the shape and placement and count of pixels really starts to matter. And you probably don’t realize it, until you start to care and do something about it… like change it. But there’s the joy of Apple. They spend so much time fussing and caring about every little pixel, every little detail. The intent? To just work. In some respects, it should be remarkable; “Any sufficiently advanced technology is indistinguishable from magic.” But really in most respects it should be unremarkable. It should just work, it should not get in our way, it should not impede the flow of our work, it should enable and empower us… and we don’t really notice nor understand why. And even something as simple as a font can do this. Does that matter? Yes it does. And Steve knew that. Many people don’t know, don’t care, or aren’t aware… and that’s fine for them.

Not me.

Think different.

Trying Trello

The new hotness in software development is “agile“. At my prior day job, it was waterfall. Sure they tried to adopt agile processes, but it really wasn’t going to happen. Due to the nature of the products and process, it just can’t be agile, tho they could try to adopt a few things and make some improvements. But at my new day job? Agile can make a LOT of sense. Take home: you can’t impart the process merely because it’s the new hotness or you think if you just adopt X process it’ll solve problems. Like any problem to be solved, you have to understand your problem fully and then apply the right tools to solve it, and that includes what processes you use.

However, it’s tough getting folks on board, so I’ve desire to try to sneak in agile stuff as we can. It’s nothing more than a commentary on human condition — we tend to resist change. If all this change is dropped on folks all at once, we’ll balk. I would too. Massive sudden change, especially when you’ve still got daily chaos and stress to manage, well… the change will be rejected. But if we can make little changes here, little changes there, over time we get there.

One thing I can tell is we all need a way to see the whole picture. We’ve got so many things going on at once, and it changes on a daily and sometimes sub-daily basis. I find myself often making lists and (re)telling my todo lists to my teammates merely to help ensure 1. I know what I’m doing and am on track, 2. that we’re all on the same page. By sharing with them I hope that if there’s a mismatch, they’ll speak up and correct. I’d rather be perceived as over-communicating than under-communicating.

But all this talk doesn’t solve the problem for everyone. The dev team is one thing, testing another, production another, sales another, marketing another… there’s so many things. Sure, we could use our issue tracking system, and there’s a lot of sense in that approach. But the issue tracker doesn’t work as well for non-dev folk PLUS it’s harder to get a 1000′ view. Yes, pictures/diagrams can make a big difference.

One thing from the agile/scrum world is having the daily stand-up meetings at “the wall”. Let’s set aside the meeting for now (again, baby steps), and just focus on the wall. I’ve suggested the wall, because I think that would be useful. Pick a wall in the office, divide it up in whatever way makes sense for us, then start populating it with sticky notes to represent all the tasks to be done. I think that’ll be useful at keeping a somewhat permanent record of the state of things (unlike a whiteboard, which will be erased eventually). Plus it allows anyone to just look at the wall at any time of the day to see where things are. CEO wants to know what’s up with Customer X? Just look at the wall. Did we ship Product Y yet? Just look at the wall.

Alas, one shortcoming is 1. we don’t have a lot of free wall space left in the office, 2. the wall is restricted to the physical. I’ve been searching for a digital wall solution and haven’t found much that thrills me. Something that we could access from any computer via a web browser (or even a platform-based app), and it would look good. But then we could also access from iOS or Android devices. In the office. Out of the office. At 3 AM, during office hours. From my desk, in a meeting on the shared screen. Whatever. Something with power to do what we need, but flexibility to work for anyone, not just the geeks.

So… I recently read this article from Joel Spolsky about “Software Inventory”. While I read it, it sounded like it was talking directly to me and our situation. I went looking at their solution:


I’ve only just started to play with it, but it seems like it could be the answer to my problems. I could see using this in my personal life, for Hsoi Enterprises, and for the day job stuff. Even if the rest of the office doesn’t buy into it, it could be useful for my own management of my tasks and issues to deal with. Being able to SEE everything instead of sorting through a bunch of text notes and to-do lists is sometimes much more useful, even if it ends up being redundant and a little more maintenance to keep 2 data stores in sync.

It’s still preliminary, but it’s promising.