posted Mar 6, 2013, 8:49 AM by Frank Adrian
The latest CD from This, Not This!, Waiting for the World, has been released! To celebrate, we're holding a CD Release Party at the Lounge of the Hawthorne Theater in Portland at 9 pm on 29 March. Our old friend Mike Ailes will be there with his band, Aina Haina, to open for us. It's going to be a great show, with lots of songs from both our first and the new CD. If you'd like to have your own copy of the new CD (or the first one), they'll be on sale there for $5. Of course, you can also buy it from iTunes or from CDBaby. I'm really proud of this album, as it's the first I've recorded and mixed for the band. And, of course, come out to see us and Aina Haina play! |
posted Oct 15, 2012, 12:47 PM by Frank Adrian
[
updated Oct 15, 2012, 12:52 PM
]
I'm doing final touch-up on the mixing and mastering for the next single from This, Not This! - a song I wrote called Dimensions. It's been a favorite in our live shows and I'm looking forward to having it finished and up on iTunes and Amazon Music sometime next week. Frankly, I did a car check on my mastering for the single and I think it actually sounds better to me than the songs on the EP which we sent out for "professional" mastering (of course, I'm biased). This one really rocks, so take a listen at the streaming "pre-release" on the This, Not This! website. Look for it when it's out there, buy it, and enjoy. Next up? Mixing one of Phil's songs - Touch of Magic - and recording harmony parts on another one of mine - Waiting for the World.
Dave Wakeling and his wife, Candace Schimp, and I will have a three hour acoustic show at Urban Decanter, a wine shop and restaurant at 2030 Main Street, Forest Grove at 7 pm on October 20 (this coming Saturday). The material will be mainly Dave's, with some covers thrown in, but I'll sing a few of my songs, too, including a couple that have never been performed live before - Icarus and Stupid Genius. I'll be playing bass and singing harmony, for the most part, but will also help Dave out on guitar on some songs. Dave, Candee, and I always have a great time performing together - wonderful songs and harmonies and you might get to hear Dave call me a wimp, live, for not wanting to play certain songs so much. A good time will be had by all, so get there and listen.
On December 7, Dave and I will be playing with This, Not This! (our electric band) at the Mt. Tabor Theater at 4811 Southeast Hawthorne Boulevard in Portland. As usual, about half the songs will be mine and I'll be playing bass and singing backup. Appearing with us will be Aina Haina and Ill Lucid Onset. Aina Haina features our old buddy Mike Ailes, who has opened for us before. This is, however, the first time we get to hear him with his band - we think it will be really great. We met Ill Lucid Onset when we played the Clark County Fair in August - they had a really good show and some great songs. We're looking forward to playing with all of these guys.
Also, if you haven't heard them yet, check out Dusty Santamaria and his band, The Singing Knives. Their online material doesn't do them justice - Dusty is a riveting performer and his performances shouldn't be missed. Sherry and I have been trying to get This, Not This! and Dusty together for a show for... well, for a long time. We hope to have a show with them soon (probably sometime early next year) - negotiations with Dusty and various venues are underway. Keep checking back to the This, Not This! website for more information. Or better yet, go there and join our mailing list, after which you can be notified of all of our upcoming stuff! See you at a show soon! |
posted Jul 25, 2012, 7:09 AM by Frank Adrian
[
updated Jul 25, 2012, 7:14 AM
]
Joe Gilder over at Home Studio Corner has a some good tips about balancing levels in songs. I'd add one other little bit of advice with respect to overall dynamics: One way to judge whether a mix's levels are right is by listening to the relative levels of "focal points" in the song. What's a focal point? At any point in time, one of the parts is usually the focus of the song, whether it's the vocal or a lead or a drum fill. Use automation to keep these focal points even in perceived volume (+/- a few dB) and make them louder than the rest of the elements in the mix (they are, after all, the focus at that time). Because your final bus compressor will key off the loudest element in the mix (OK, it's a bit more complicated than that, but I don't want to go into it now), the compression will be more even and the overall mix will have fewer compression artifacts. As an added benefit, it will make the mastering process easier. I can hear the complaining now - "But, Frank, I've just reduced the drum volume to put them in the back of the soundfield. Now you're telling me to turn up fills?" Yes. I'm telling you to bring the drums forward on fills, assuming the fill happens to be the focal point at that time. Drummers tend to hit fills harder than normal rhythm strokes, so we're used to hearing them get louder - it works psycho-acoustically and a bit more volume won't break the fourth wall. Same way with that killer bass run. Or that interstitial guitar lick. You don't even have to increase their volume that much - you can also use automation to slap an EQ on the focal points to boost them in the presence band (3-6 KHz, season to taste) or turn down their reverb a bit. It will make them stand out without as much overall level change - we're talking psycho-acoustics here, not numerical equality. Getting focal point levels right will go a long way towards making your mix even. And an even mix is one of the hallmarks of a good mix. |
posted Feb 13, 2012, 9:13 AM by Frank Adrian
[
updated Sep 19, 2012, 8:57 AM
]
There is no "true" chili. Those of us who love this spicy concoction understand this. For every region, there are different flavors. For every recipe you know, there will be a dozen others you don't. And almost all of them taste good, in the right place and at the right time. You can find some basic commonalities - a chili often has onions and some sort of pepper, for instance; but for every "rule", there seems to be a recipe that shows that the exception can be just as tasty. Chili aficionados have responded to this uncertainty by generating a plethora of variations. And, even if you hand a chili cook a recipe, he or she will usually modify it somehow.
It's the same with software development processes. We are handed cookbooks full of procedures and rules. Sometimes these fit. Sometimes they don't. The reasons why things might not fit come from many different directions - the nature of the market and its timing; the nature of the organization; the nature of the product, its delivery mechanism, and the tools used to construct it; the nature of the team - all of these can impact whether or not a particular part of a process is effective. More importantly, sometimes these forces can make a portion of a process worse than ineffective - it might take more work than it saves, creating more work for your team without providing additional benefit. As such, it's clear that processes often need to be modified.
In addition to removing inefficient practices, processes can be improved by adding or replacing procedures. I've seen traditional processes improved by importing steps from the agile world - using TDD practices or delivering frequent intermediate builds can often help a traditional team achieve better quality. Depending on the product and frequency of market or requirement changes, an agile methodology can be improved by formalizing and adding a bit more structure. The main issue is to always be aware of what's working and what's not working and fixing the thing's that aren't.
Occasionally, you'll want to change processes anyhow, just to boost your team's efficiency via the Hawthorne Effect. Plus, introducing teams to new process practices will help keep them fresh and ready for change if (actually when) your team's environment changes and you need to change your processes in response.
So, if you're the leader of a team, don't be afraid to change your processes to make them more effective - make them your own. Keep trying to make your team's development and project management processes more effective. It may take some experimentation to come up with the right mix of process "ingredients", but the payoff will be in the tasting - when your high-quality product arrives on time. |
posted Feb 11, 2012, 5:16 PM by Frank Adrian
I made mention on Facebook that I was reading a book on Haitian Vodou and how it was possible that Ogun, being one of the technical lwa might be useful to practitioners of software engineering. But I think, at least for me, now that I have read the book, that the Simbi are a much better match. To see why, let's do a quick description of each...
Ogun is the lwa of iron and the forge. He is also a mighty warrior. If you think of a cross between Mars and Vulcan, you will get the idea. So, although Ogun can be used for technological purposes, he is much more suited to designs of rifle barrels and predator drones than run-of-the-mill technology. In addition, Ogun is a very powerful and prominent lwa. Asking Ogun to help with normal computer issues would be like using a tactical nuclear weapon to swat a fly.
In contrast, Simbi, the water snake, is able to exist in both salt and fresh water and, as he mediates between these two world, he also mediates between the upper realms and the crossroads. He one who leads souls from the visible to the invisible starting at Legba's crossroad and who leads the invisible to the crossroad to accept the sacrifices of those who are visible - he is the hermetic Mercury. More importantly, he also is the lwa of rain. And, just as the rain brings creation to the parched earth, so does Simba bring the creative element in his wake. In addition, just as water heals the earth, so is Simbi a healer whose knowledge of the herbal world allows his followers to heal others. As the lwa of communication at the speed of light, he is very handy with computers and other telecommunications devices (which are often in need of repair). Finally, he is much more tractable than Ogun and more useful to ask for help in more common technology matters.
In addition to being attracted to Simbi's aspect of healing the world, I was also born under a water sign, further connecting me. His water aspect explains my love of long baths and showers (the reason my house has two water heaters), and his serpent nature explains why Kundalini was the only form of Yoga that ever resonated with me.
And, I think this morning he helped me get my audio interface working again. I had an insight that maybe I was plugging the unit into my Firewire card instead of the PCI interface card. I looked at the back of my computer system and at the connection and It all looked OK. I deracked the interface unit to get its serial number to register it so I could submit a trouble ticket. As I re-racked the unit, something continued to nag at me. As I looked at the back of the computer system one more time, I realized that the first time I checked, I was mistaking the audio interface's PCI card as a video card because of the connector at its bottom that looked like a VGA socket. Connecting the audio interface to this card made the system work - the initial insight was correct.
Now I can't say for sure whether or not this insight came from Simbi, but just to be sure, I left him a cup of cola under a nearby tree (I didn't have any black coffee or rum on me, and he said cola was fine). |
posted Feb 7, 2012, 8:49 AM by Frank Adrian
Building code is hard. Sadly, the designs you create, the code you write, the tests you devise are all, in the end, parts of the system that can fail. A corner case in the design can be exploited to crash the system; a mis-coded logical condition can cause unexpected behavior; a set of tests you thought were complete may not be and may allow defects to slip through... Yes, programming is a difficult mental task with only your wits standing between proper operation and chaos. But, even with the best mental effort, defects will creep in. With any luck, these defects will be detected by some other means and you will have an opportunity to fix them before your system is delivered to your customers.
When should defects be fixed? As soon after you find them as is possible. Yes, there are always other things to do rather than fix defects - new components to be designed, now code to code, chatting with your BFF via facebook... OK, maybe not so much the last one, but there are many advantages in fixing defects quickly and some real dangers in allowing them to linger. When a defect is first discovered, the person who finds it is familiar with what has happened. The system on which the defect was found is more likely to be available for inspection. Waiting for weeks (or even days) to start working on the defect will reduce the amount of information available to you or will potentially require you to go through a possibly fruitless reproduction cycle. Stacking bugs like cordwood also adds to basic project overhead - defects need to be scrubbed and triaged, people need to decide which defects deserve their attention - this can add a significant amount of work to your project team. Leaving defects until later also increases the chance of a project slip. In general, well-defined tasks, like new features, have lower variability in their duration than do more exploratory tasks, like bug fixes. New features are unlikely to uncover surprising architectural issues and, if they do, they can often be solved with no schedule impact by a decision to omit one or more features. When you find a defect later in the game your choices are more limited - fix it and slip or ship with the defect in the product.
There are also second-order costs associated with leaving defects in code. People start coding around buggy portions of the system - their code becomes distorted because the foundation they are building on is shaky. What "proper operation" is in the face of known defects is often daunting to determine. As such, testing and writing tests become more difficult, fewer tests are written, and the code, over time, becomes worse and worse. And people become scared of tackling changes in buggy code, worried that they'll be the one that will be stuck with re-writing the buggy mess (or even worse, be stuck with enhancing it into the end of their careers) - it makes coders tentative and reduces the amount of aggression a good programmer needs to tackle a batch of code.
So, make no mistake - failures, of build systems, of design, of code, of testing, are a cancer, eating away at the stability of your system. They are a symptom that something is wrong. A diagnosis must be made immediately and, if you are doing things right, remediation should also applied. immediately Waiting to fix failures is a recipe for disaster. Don't fall into that trap - fix failures... now! |
posted Feb 6, 2012, 8:37 AM by Frank Adrian
Everyone likes a sale. I was reminded of this yesterday while grocery shopping. As I checked out, the clerk asked if I was going to get two of an item, as they were having a "Buy one; Get one free" sale on it - I hadn't noticed. I thanked him profusely as he rang up two of these items (the second free) and I ran back and got the other one.
Although I appreciate what the clerk did for me, this post is not about customer service - though it could have been, because this is a stellar example - but on the notion of the sale itself. "Two for the price of one" is a concept we can often find in our projects and these "two fer"s can drastically improve your product's quality and utility. Let's say that a customer has requested a change in code which (due to no fault of your own, of course) has not been refactored in a while. Opening up the code to add this enhancement provides a perfect opportunity to refactor the code and a good developer will do this while making the change. Similarly, combining similar user stories or required features impacting the same areas in your code often allows you to make changes more efficiently. Any story about UI changes can usually be combined with another item (or five) in your story list around the same area to make a combined story that might take less time to design and code than if you did all of them separately. The same is true in the construction of unit tests - usually, much of the infrastructure from one unit test can be reused and this is more likely to be done if tests for multiple functional items in the same area are written simultaneously.
There are also places in project management when you can use the "two fer" philosophy to gain additional efficiency. For instance, there are times when meetings must be held - a review of user stories, discussions of new designs or architecture changes, etc. By combining these meetings with others having the same attendees or similar purposes, you can minimize disruption of people's work (although beware combining unlike meetings, especially where there really are topics that half of the attendees are not involved in - more about this later). Personally, I find that grouping my one-on-one meetings with my employees minimizes the disruption to my daily routine. Preparation is simpler and I'm less likely to forget topics. The day of the week I choose for these may be booked pretty solid, but I'm not interrupting tasks on my other days the way I would if these meetings were done "onesy-twosey".
So look for opportunities to kill two birds with one stone in your projects - these chances come about more frequently than you think, and taking advantage of them can save you, your people, and your project both time and effort. |
posted Feb 3, 2012, 1:27 PM by Frank Adrian
The posts will tend to be a bit late on Monday, Friday, and some Thursdays.
Mondays and Fridays can be explained by two photos:  The first is me after my freshman year in college when I was working construction, and practicing or playing with a band three or four nights a week. The second is me now (well, actually about a year ago). You may notice the size differential (Note to the visually impaired: I appear to be much narrower in the first picture. I am also not wearing a tie)...
In short, I am trying to get closer to what I looked like in the first photo than to what I look like in the second. To do this, I am cutting my caloric intake drastically and walking and exercising more. Part of this routine is taking the train to the office on Mondays and Fridays. As I have to walk about a mile to and from the train on each end of the trip, taking the train allows me to walk four miles each of these days. This doesn't greatly affect my daily routine, except for blocking the early pre-job hours to work on the daily essay. Because of this, Monday's and Friday's posts may be delayed slightly.
But what about Thursday, you may ask? That's a bit more mundane - I have a some standing morning meetings that could get in the way on Thursdays. Other than for these minor inconveniences, you can expect my post fairly early each morning.
Oh yeah - two other things... I'm not going to post on weekends (mainly because I think I deserve some days off) and I no longer have guitar face when I play (I hope). |
posted Feb 3, 2012, 10:11 AM by Frank Adrian
[
updated Feb 3, 2012, 11:08 AM
]
Each platform you support costs your engineering team extra effort. Each platform you code to not only has different APIs, but also different quirks that the same API calls have across different versions of the platform. You'll have to write your code portably for those parts amenable to such a treatment and have separate code bases for those parts of your code that aren't. This goes for OSes, UI frameworks, databases - any significant platform upon which your code is based. It's obvious that adding support for multiple platforms will increase costs.
But more insidious are the non-obvious costs associated with each additional platform you support. Because you must separate portable and platform-specific portions of your code, your architecture becomes more complex. Unless you're very lucky, adding new features will take longer because their platform-specific parts will require multiple implementations (and we will not touch here on the idiocy of a disastrous decision like allowing product functionality to diverge on different platforms). The build system will become more complex and more error prone. Unit tests will become more difficult to implement. All testing will require more test cases and more time. You'll need additional hardware and software to support each platform. And this is just in engineering - when you hand off the product to a support organization, the same fun is duplicated and your support costs will balloon. Sales will need to target different customer bases (whose markets they don't actually understand) and advertise in different places to reach these new customers. Costs of sales will skyrocket.
In addition, from a usability point of view, most products that target multiple platforms suck. Either they work well on their main development platform and suck on others or they suck on all of the platforms they run on. Why? Because platforms differ so much these days and have so many features that the features required on one platform will not translate to another. You'll either be stuck with separate products for each platform, which customers will hate when they can't easily switch back and forth between platforms, or a compromised solution, which customers will hate because the feature set isn't proper for the platform. It's an awful dilemma.
But things are a bit better with web-based interfaces, aren't they? Well, yes and no. Assuming you have an application that is amenable to web-based implementation (which is not always a given), you still have the plethora of browsers to support - the browser is a platform. You'll have to find a UI widget set that runs well on all of these platforms (and good luck with that, by the way) or code your own. Your days will be a tedious slog through minutia of browser bugs. Every Opera and IE6 user will complain that your code doesn't work right, and you'll never know when Firefox is updating. Your life will still be awful - just not in quite the same way.
The moral of this story - support as few platforms as is feasible.
The good news is that mature markets in software seem to ultimately devolve to a simple oligarchical structure - one major player, one minor player, and a plethora of also-rans. You'll only have to support two platforms to cover the majority of the market! The bad news? Your two main platforms (Windows and OS X, Android or iOS, IE or Safari) are going to be radically different in structure and in capabilities. You might be able to reuse some internal logic from your core code but, in reality, you'll be coding two separate apps. And the also-rans? At least one major customer with deep pockets will tempt your business with dreams of filthy lucre beyond your imagination if only you would support Sneezy, Grumpy, or Dopey (because they made a poor decision to standardize on this platform).
So what do you do? First, you stick with a single platform as long as you can. Perhaps, if you make enough money with that, people won't bug you about running on other platforms. Ha, ha! That was funny - businesses can never have enough money! So, second, each potential new platform must go through a rigorous cost-benefit analysis, making sure that all of the non-obvious costs - from engineering, support, and sales - are accounted for and that the all-to-real possibility that the product may not sell well on the new platform is taken into account. Finally, when there's no pushing back, when your hopes are dashed, and all your options have run out? "Prayer, Mister Saavik - the Klingons don't take prisoners." |
posted Feb 2, 2012, 11:14 AM by Frank Adrian
The assistant and myself will be hanging bass traps and fishing cables through walls. Still waiting for the headphone distribution system to arrive. Next stop - wiring. It's getting closer... |
|
