RailsThemes is a project that I’m working on with Eliza Brock and Luke Flener. It is like WordPress themes, but for Ruby on Rails applications. Basically you purchase a theme on our website, and then you can install it on the command-line and have a site that is easy on the eyes in a matter of minutes. Traditionally, you would have to spend a lot of time and money to get a good looking theme.

What day of the week is it again?

Eliza lives in Nashville. I live in Indianapolis. Yet we were able to spend about two weeks together in the same location working on the project over the course of a couple of months due to some creative scheduling.

The benefits of working in close physical proximity are fairly well documented (see Peopleware). For me it is speed of getting feedback, better design sessions, and general morale boosts.

When the project first started, we talked on the phone and I said that I needed to find a weekend to come down there so we could work together. Eliza reminded me that I can work whenever I want to, so I could come down for a few days in the middle of the week and that would work. I said that made sense, and then five minutes later, said, “OK, well I’ll find a weekend that works and then I’ll come down,” and then immediately re-realized that I could come down on a weekday. Old habits die hard I guess.

So I picked a Monday through Wednesday trip and drove down and back while listening to audio books (a good use of the dead time.) Later iterations of the “work weekend” as we came to call them had me riding on the Megabus to free up time to work on things or read or relax. We would get a lot of work done during those periods, so it was worth the cost of traveling. I went down to TN, she came up here for a week or so, we met in the middle in a Kentucky state park and used a MiFi to get internet, and I went down there again right before RailsConf to finish up some things. So overall, a pretty productive way to get things done. We could also work on things outside of these blocks, but they were very effective in staying on task and ensuring that the time was used well. The opportunity cost of traveling made it really unappealing to waste time.

Scheduling things like this does take its toll. At some point in the last month, I tried to order the Wednesday lunch special and after a puzzled look by the waitress, was informed that it was Friday…

The installer

The installer is what I’ve most been working on for this project. I also worked heavily on the payment gateway and backend tools to help us create and manage themes. We came up with the idea of a command-line installer to allow devs to quickly get up and running with installing a new theme (full source and history here). The idea is that the installer does most of the heavy lifting of looking at your project and determining what files you want, and then asks the server for the right set of files and installs them correctly.

I researched how to make a gem, and used Bundler to generate the scaffolding. Then went through and developed it using (mostly) test-first development. Sometimes there were issues that were easier to track down by running the installer on my machine, and then I could make the appropriate changes to the tests afterward. I think this is a good example of “spike and stabilize”.

One cool thing that I ended up using was fakefs. This allows you to stub out file system calls and thereby test things without needing to actually touch the file system. This makes for more repeatable tests, reduces the need for cleanup, and possibly speeds up the specs as well. Before using it, I had functions that I was invoking that would operate on the filesystem, and then would mock those calls. However, fakefs works by setting up a fake filesystem (hence the name!) that you can run your tests on and then make assertions about the state of the filesystem. Overall a much cleaner solution.

Progress update: Early-access beta

We still have a few kinks to work out, but we have themes and people are starting to help us test them out. If you work with Rails projects and you haven’t signed up yet, check out RailsThemes and we’ll let you know when things are rolling.

We are planning on coming out with a new theme every month, and some extensions like themes for emails that you end up sending out through your app.

General thoughts

It’s too early to say whether RailsThemes will be a financial success or not. I think the next couple of months will shed some light on this. However, I’m glad that I worked on it so far. I had been wanting to work with Eliza on a side project of some sort for a few years. I think we made an ambitious but achievable schedule and really executed on it. My confidence to be able to do projects has gone up. I better understand how hard it can be to make something.

I think regardless that we are creating value, and that good Rails themes is something that I wanted to have in the world. If things don’t work out, I also think it will be a good data point for me to refine future business ideas.

Original article: What I’ve Learned From RailsThemes So Far

(Having trouble seeing the slides? Try here.)

Original article: RR for Test Doubles Presentation

(Having trouble seeing the slides? Try here.)

Original article: Making Recommendations with Apache Mahout Presentation

I am working with Jason Yip to better understand how people think about solving problems. Specifically we are interested in the differences between “experts” and less expert people in a methodology.

For this first step, we are looking to collect challenging Agile scenarios. These should be the hairiest, most difficult, most challenging Agile situations you’ve found yourself in. The preference is for scenarios that you have directly experienced yourself rather than hearsay or hypothetical scenarios. It’s not important whether you were successful in meeting the challenge; it might even be better if the scenario is one where you failed. We’ll then pose these scenarios to different people and see how they think about solving the problem.

We are doing this to try to improve everyones’s understanding of how mindsets change with experience and potentially to help people gain mastery faster in the future. Also, it could help with debugging mental models, which would be useful in other contexts (lean/agile adoption, lean startups, etc.)

Here are the three specific things that I am asking. I am hoping that it will take ten minutes or less. Thank you!

(Having problems seeing the form? Click here.)

The method to the madness can be seen here.

Original article: Think Like an Agilist Challenge

I got together with Alex Toumey, Kyle Shipley and Wes Winham on April 16 for an event practicing lean startup concepts.

We started off by pitching ideas that we thought were interesting and needed some validation. At one point, we riffed on one of the ideas by coming up with “Etsy for baked goods.” The idea seemed kind of hokey at first, but the more we talked about it, the better it seemed. We put aside the other ideas for future exploration, and talked about our thoughts on the idea. We came up with a quick description to make sure everyone was on the same page: a marketplace for people to buy and sell local baked goods. Seemed good. What better time to test this idea against cold, harsh reality?

Brownies, or bullshit?

Next, we sketched out some basic hypotheses and some questions to test these hypotheses, and contacted friends and family to get some feedback. Someone took pictures of these, I’m sure, but I can’t seem to find them, or I’d post them.

Two keys that I thought we did quite well at this point were:

• not sticking to a set script
• and asking for references at the end of the conversation

At this point in the process, asking for too specific of feedback would have hampered the quality of learning that we were getting. This is something I learned when doing Lean Startup Machine Boston, and Ash Maurya also references this in Running Lean.

By asking for references, we expanded the number and quality of people that we were able to contact in a short period of time. It was a bit surprising how well we did just by calling people we thought might know a lot about baking.

• Person 1
  • Left voicemail
• Person 2
  • Tried to start up a basic Christmas cookie selling business — ran into VA licensing issues and didn’t pursue further
  • Researched commercial kitchen rental opportunities — too much hassle
  • Some temporary licenses available in VA
  • farmer’s markets have vendor licensing
    • produce vs. baked goods difference?
    • produce can be sold easily; processed food is regulated
  • Recommended checking our local county web sites
• Person 3
  • Had read about a tangentially-related case study involving South American women selling baked goods that were shipped to America
  • Feels like cookies are more of an impulse buy item
  • Warmed up to the idea of “ethnic food in your neighborhood”
  • Has a sister who is a pastry chef if further research needed/desired
• Person 4
  • Will contact again later — some hearing issues over-the-phone
  • Has been encouraged to sell at farmer’s markets, but hasn’t taken the plunge
• Person 5
  • Liked the idea
  • Wasn’t very worried about food safety, going to someone’s house
  • Liked the idea of local food that was not going out to eat, seemed healthy and would save her time (no preservatives)
  • could see using night-time meals as well
  • wonders about FDA or other regulators
• Person 6
  • Thinks she would have been excited about the idea when she was a stay-at-home mom
  • Would only consider participating if she could pre-fill orders (guaranteed purchases before she started baking)

After lunch, we worked on a business model canvas for the idea. This is something that I had wanted to do for awhile, so I brought my Business Model Generation book and we took a crack at it. I thought that the process gave us good insight into the challenges of the business.

After fleshing out a couple of sections (click picture to enlarge)

The "finished" business model (click picture to enlarge)

If we were to continue working with this idea, a solid next step would be to take the most risky assumptions on the business model canvas and start testing them for validity. In my mind, getting a little more perspective on the demand from buyers and sellers for our chosen idea might be a good plan. I’d probably label the riskiest hypotheses with hot pink sticky notes to make them stand out a bit.

In the process, we came up with a few directions that we could head with the baked goods idea that were slightly different (ingredient label maker, targeting more professional services), and also have a list of other backup ideas that seem useful.

I had a really good time going through the process with everyone. I thought we got a lot done in a day going from just an idea to getting a lot of thought on the problem, and building up our customer discovery skill.

Afterwards, we played some Halo 3 and it was a ton of fun!

Our next time doing this will be Sunday, May 22nd, 2011. Contact me at panozzaj@gmail.com for more details.

Original article: April 2011 Customer Discovery Day

Pregame

Make sure you have alerted friends and acquaintances about the weekend so that they know they probably won’t see much of you. This helps clear any potential distractions. It definitely helps to clear your plate as much as possible. At one of the competitions I had to fix something at work that couldn’t wait, and it took half of Saturday up. As you can imagine, it was frustrating for me and I wasn’t much help to the team.

Before the event might be a good time to start eliciting help for electronic voting. Something along the lines of, “hey, I’m doing a business competition this weekend, and part of our final score comes down to people texting a certain number.”

For the sake of everyone at the event, if you are pitching an idea, do some basic groundwork on the idea. Nobody wants to hear your pitch if the idea has already been done or is way too big for a startup weekend or is mumbled. You are just wasting everyone’s time. If you have an original take on an existing idea, fine. Just make sure you know enough about the environment you are considering working in to actually know about prior art. An hour of your time saves sixty people from hearing and voting on a minute pitch. It might sound equivalent, but it’s a net gain in terms of attention and energy. There were about forty pitches at the last startup weekend that needed to later be voted on, which took time.

Pitches

Along the same lines, when at the pitches, listen for ideas that are pretty well-defined and that preferably have some sort of validation already. About the worst thing you can do is spend half of the weekend figuring out what you actually want to work on. About as bad is trying to do something for awhile and then basic research suggests that the idea has already been executed well by someone else. At that point the team flails for a few hours. Not a good start.

I generally pitch something that meets the criteria above and/or look for an idea and team leader that I think I will be able to work well with. I also check out the people who are joining the team and try to make sure that they are an impedance match. Talking with people before the event gives an idea of who I can most easily work with. You don’t have much time to butt heads, so picking a good team is really useful. Plus, nobody wants to spend the whole weekend working without having a little fun. I want a good story to tell, and picking a bad team, even if only for a weekend, is not a fun story to relive.

If you are just doing a small event, the same pitching process happens, and you can just pick the best idea out of the ones that you have come up with. Make sure to write down the other good ones in the event that you are going to do another event and want some ideas.

A New Team

Being productive with a team of strangers works best when you get off to a good start. Here are some patterns that I’ve observed.

Go around and introduce yourself and explain why you are interested in working on this idea. This lets everyone get to know each other, notice any biases or preconceived notions, and generally start forming around the idea of working on a shared project together. You can see why everyone picked this idea and team as the one they wanted to work on, and it leads effortlessly into the next time block.

This time period is always interesting because people may still join or leave the team. Just stay focused on the process, and the introductions and problem solving will work themselves out.

Next, everyone goes around and says at a high level what they think the idea is as they heard it from the person who pitched it. This puts the idea out there in a few different forms. After this comes a period of adjusting to the different viewpoints and emphases. Hopefully everyone is generally on the same page, and gelling occurs as you work out the key things that need to happen.

Generally at this point, it makes sense to solidify the problem you are trying to solve. Any talk of product or solution should be written down on a separate sheet of paper, preferably at the other side of the room. You must figure out the problem you are trying to solve before you can reasonably attempt to solve it. This will help marketing and development efforts greatly. You may identify many different problems or potential stakeholders, but for the sake of time it makes sense to focus only on the most valuable or easiest segment.

At this point in the process, I think it makes sense to take a step back and do some administrivia. Figure out who will be your team communicator that talks with advisors or other teams and communicates at startup weekend status update meetings. These can consume a lot of time, so it’s best to have one person to handle this. This person is still involved in the workings of the startup, and also has this extra role.

Keeping with administrative tasks, one person should be the head time keeper, in charge of letting everyone know when the next meal or meeting is. At this time, go over the whole weekend and get a lay of the land. You want to budget enough time for everything that you want to do during the weekend. Ask everyone if they are free for the whole weekend. Maybe someone has a soccer game that they need to watch, maybe someone has a party that will take a couple of hours. It’s useful to know these because then it isn’t a surprise and everyone feels that they can do what they need to do without being “that guy”.

Are We At The Solution Part Yet?

Well, if you are using a lean startup methodology (generally most applicable to Lean Startup Machine events), now is the time to validate that this is actually a valuable problem to solve. It’s part of producing the value that you need to produce (validated learning.)

Next, figure out a potential solution path. This should include what specifically you are going to build next, what the goal is for the weekend, and extensions. It’s good to start with a vision of greatness and then taper it down so you can show some progress. For more tips on defining the solution, check out Jared Brown’s post on defining the message of your startup.

If you are using lean startup techniques, at this time you should validate as you are building the solution to ensure that you are building the right thing and that it resonates with people.

Iteratively build until you just about run out of time. I suppose not much needs to be said about this.

Finally, work on the pitch to make sure that you don’t blow your time. Often you will only get a few minutes to describe what you did during the whole weekend to a group of people that has heard nothing of your idea. I’ve seen way too many teams blow this with irrelevant information. You are completely wasting your time if you talk about any of the people on your team unless they happen to be super-famous. The judges don’t care about who is on your team, they want to see what you got done or learned during the weekend.

Although I recommend practicing the final presentation a few times, it’s definitely not enough to have a good pitch and no product. A demo is worth a thousand words, which happens to save you quite a bit of time. You need to have something to show. If you can’t make a full product, make a prototype. If you can’t get to a prototype, lay out some screenflows. Any artifact that represents your thinking and the conversations you’ve had is better than just words. Arguably the screenflows should come before the prototype so that at any point you have something that best represents your product.

Random Thoughts And Question

I’d enjoy seeing some more non-tech startups at startup weekends, and even working on one. Also, some more non-profit or philanthropic companies would be interesting. The key here is coming up with a business model and proving the validity. It seems like this would be doable in a weekend.

Have you done a startup weekend? Does this experience relate to what you have seen? I haven’t won any, so maybe I’m going about this all wrong…

Original article: Startup Weekend Patterns

When I first heard about the LSM in Boston, I signed up. I asked Wes Winham from Indy to join me, and we set off to Boston. This post talks about what I did and saw, and what I learned in the process.

My experience

I had been reading the various resources of the lean startup community for over a year, and was excited to actually put the principles to the test and test out my skills. Doing is a different beast from reading. My personal goal was to work with the team I joined up with to demonstrate that we could work through various difficulties and learn more about the lean startup methodology. I thought whatever team I joined had a chance to win, although it was not my focus.

Our final presentation (PDF) gives a good overview of what we ended up doing over the course of the weekend.

The energy and intelligence of the people at this event was a little intimidating at first. There were fifty extremely smart and capable people present. I was a bit out of my element in a city halfway across the nation, but then just started talking with people and things seemed to go well. I enjoyed the networking before the event began. It was clear that everyone was feeling each other out a bit to figure out who they wanted to work with. A weekend is not a huge time commitment, but everyone wanted to have a good experience.

After a round of pitches, everyone cast votes for the different ideas. The top ten idea presenters were chosen as temporary team representatives, and everyone walked around and tried to form into teams. It was a bit chaotic.

There were a few ideas and people that seemed most interesting to me, so I walked around for a minute or two getting a sense of the room. I settled on a pitch that was billed as a last minute appointment filler. This could be something that slotted people in for busy service providers, or something that filled up empty slots for not so busy service-providers. It might have been something for service providers, or something more for end users. It seemed open-ended and valuable enough that we could explore some different solutions in the space throughout the course of the weekend. I was excited to work with the team of guys that were interested in the problem as well. It ended up that I was the only “developer” on the team. The rest of the guys billed themselves as “marketers”. (LSM also had the distinction of “designer”. These roles were pretty open and just served to try to get a range of skillsets at the conference.)

[In]validating our initial assumptions

We immediately sat down to meet each other, clarify the idea in our head, and try to explore the general space around the problem. We came up with some assumptions about the problem space and started coming up with ways to test them. Our goal for the night was to come up with a survey that we could send to end users (clients of dentists, doctors, spas, etc.) of a last minute appointment filler system to see what their problems were with scheduling appointments. We mapped assumptions to questions in a way that reminded me of software requirements traceability.

I was out the next morning due to a short-term illness and the fact that my production server at work wasn’t feeling that great either. When I felt good enough to fix the server problems, I headed back to the meeting place. The team had learned in the meantime that clients of service providers did not perceive the problem of scheduling appointments with service providers to be a large pain point, and that they were likely unwilling to change doctors or other differentiated service providers for a quicker appointment turnaround time or for a discount (these were some related ideas that we toyed with.)

So our assumption at this point was that the service providers would need to drive the adoption of this tool, and we sought out to find what problems they had with the appointment process. We accomplished this by calling people we knew in fields that had appointments, and by cold-calling various dentists and spas because we guessed they might be open on a Saturday.

One of our initial assumptions on the service provider side was that our idea would probably only be useful if doctors had 95% or less utilization, and they cared about utilization. If these were true, then we had a problem that needed fixing and an angle to sell a solution. What the specific solution was would have been determined later in our process. However, we learned two final things…

It turned out most service providers did not have a problem with people cancelling at the last moment. Most people give at least eight hours cancellation notice, partly because of late cancellation penalties and partly because of common courtesy. Also, basically everyone we talked to had a manual system in place to put people down on a list and call them in the event that an appointment filled up. So they actually have really high utilization. Further, the two or three unfilled appointments—per week—don’t really concern the people at the office. We proposed an email or test messaging system to one provider who had a few openings per week, and she replied that they actually had that feature in the schedule management software that they used, but didn’t care enough about the problem to figure out how to use it! This was pretty damning evidence that we were not on the right track.

We decided to take what we learned and pivot to a different market: high-end salons. We reasoned that these places might have appointment woes similar to what we ruled out for doctors and dentists. However, it was much the same, and was compounded by a slightly different problem. Most high-end salons actually employ independent contractors that are responsible for driving in their own work.

Reeling at this point, we talked with a few people around home base. The team decided to leap. While a pivot would be grounded in the learning that we had already obtained, a leap implies that there is not much salvageable from our initial exploration of the problem space. We had a moment of despair, then started a huge brainstorming session.

At this point, the weekend gets a bit fuzzier. The sheer volume of ideas that we had was very large, and we took action on a few of them to try to see if there was any easy viability. Time definitely played a role at this point. We didn’t want to show up to the final presentation with the worst presentation by showing little learning. We discussed a lost key retrieval service, used facebook to explore an online university lead generation idea, walked around MIT asking people about their caffeine preferences for a new product based on green tea, and called a couple of unsavory businesses. For me as an admittedly extroverted software person, I definitely needed to get out of my comfort zone to do this. I think coming in with a mindset of exploring people’s problems and genuinely trying to help enabled me to get over any hangups about talking to people about ideas that I had no intention of implementing that weekend. After the leap point, we mostly stuck to the customer discovery portion of the customer development process.

Toward the end of the weekend, I talked with a few people and tried to understand the process that they took and the key things that they learned. It would have been interesting to have a networking session before the final presentation. Our presentation went well overall, with LSM judges tweeting out some key findings we had. Our team won the “Old Yeller” award for taking our initial idea out in the back and shooting it.

So that was the narrative, next comes the reflection.

My Biggest takeaways

Steve Blank says that no business model survives first contact with the customer. I now more clearly see the reason for this: people in the business have mental models that probably conflict with reality. Assumptions build a structure to view the basic details of a business. With a given unvalidated mental model, like a Platonic ideal, a number of valid businesses seem possible. However, once inaccuracies in the model itself are revealed, companies must learn how to adapt to this new knowledge. The key is figuring out invalid assumptions as quickly as possible to learn as quickly as possible.

I realized that validating ideas quickly was useful for staying detached. If I stay inside the building and do nothing but think or talk to others, I just get further from reality while becoming more certain of my idea. Boyd posited the spiraling confusion in his work on the OODA loop, and this idea clicked for me this weekend. Getting out and trying to quickly invalidate an idea through experiments seems to be a good way to let go of small ideas that I have every day with a clean conscience. “Kill your darlings”, I guess.

Seeking failure gave me unnatural feelings. There were several times throughout the weekend that were very high, and several that were very tough. At one point, we realized that our initial idea had very little validity, and so we chose to start from basically square one after doing some massive brainstorming. The emotions probably resembled a startup on a micro scale. I liked that the teams were pretty laid back though; everyone seemed to have a good sense of humor while learning a whole lot.

We ended up exploring about six ideas to some degree throughout the weekend, with many more than that killed during the idea generation process. With our total waking time of 24 hours, this meant the cycle time of our ideas was about four hours each. The way we accomplished this was by having a lot of parallelism after our initial idea did not seem to work out. This was partly because of the time format of the weekend. When we chose to leap, we only had half the weekend left. It was also partly because we didn’t really have a strong direction to head in.

Everyone agreed though—it was much better that we spend less than a day figuring out that our initial idea didn’t make much sense because of lack of demand then to spend months or years developing a solution that nobody actually wanted. This was the kind of success story that I went to Boston to get. We had an idea that, on paper to us, seemed great, but when exposed to reality broke down.

Toward the end of the weekend when we did a bit of retrospection, I realized that the quick exploration process seems to be a useful way to start a company. You start with a few seed ideas and some smart people that all want to use the process to find a viable idea, and you put the ideas through a customer discovery and customer development pipeline. Ideas that seem squashed are discarded and replaced with other ideas. Others are iterated and pivoted until they become more viable. In this way, you quickly learn what doesn’t work, and try to find some pain. It seems that everyone should stick to the same general process. The nice thing about the parallelism is that most of the time it takes a little while to get feedback that is actionable. So instead of waiting around, you can explore another idea at the same time.

Useful Tactics

Calling the west coast or Hawaii is a good way to “extend” customer development time when businesses on the east coast are closed. This is something that we wouldn’t have thought of without the time constraints imposed by the weekend format.

Finding the ultimate purchaser of the service has a lot of value. If you are talking with someone that does not know the value of a potential service to the business, then you are likely wasting time. We got value out of talking to receptionists and friends in the industries we targeted, but had we progressed much further we would have needed to talk to the ultimate purchasers of the system. I think Steve Blank talks about this in Four Steps to the Epiphany, but it was one of those things that I forgot about until it was a problem for us.

The next LSM

In retrospect, it might have been valuable to choose some of the related ideas that we generated during our initial approach of validating the ideas. When we came to the time when we leaped, we might instead have chosen another angle of attack on the problem. Some ideas included more general inventory expiration problems: unused machinery rental, donuts that the donut seller wants to get rid of, a table in a restaurant that they are willing to fill up for a 10% discount.

The team right next to us (Wes’s team) seemed to have a really organized process. One of the team members was an agile meeting facilitator, and they used pomodoros and personas and use-case mapping to work through the process. They actually ended up making $60 by the end of the weekend with no actual software product, with an additional $120 that came in by the end of Sunday! But I’ll let him tell that story.

I think there were times when we could have been more organized in our process of writing down assumptions, exactly how to test them, and what we would look at as a validated or invalided assumption. Having clear assumptions with clear ways to measure seems important. If you talk to fifty people and get a fantastic response to your problem, it’s a clear green light to continue with the idea. What’s harder is making that decision when the data is fuzzy. At that point, you need to try to change how things are worded in order to calibrate the questions asked with. Talking with people directly gives really quick feedback on what people respond to and what things they don’t seem to care about, as I found out when wandering MIT’s campus and talking to people.

I felt like the presentations at the end were potentially the most interesting portion of the weekend, but in Boston’s case they were cut short. While typically six minutes with three minutes of Q&A, each team only had six minutes of combined presentation and Q&A. I didn’t fully understand why the presentations were cut short when it was the best time for each team to present what they learned and the process that they took to get that knowledge. The process was important, and I would imagine that some of the teams came up with some really useful insights they didn’t have time to share. Oh well, I guess that’s how it goes.

On the whole, I was glad that we got a chance to do some idea validation / invalidation over the course of the weekend. I’m quite glad that I went.

If you read through this article, thanks! This is the kind of experience report that I wish everyone gave when they go to interesting conferences. At the least, hopefully it’s a good starting off point for conversations that we have in the future.

Original article: My Lean Startup Machine Boston Experience Report

A ton of resources on lean software engineering (I have not specifically investigated these sublinks, but seems like a recent, solid, quality page. I’m pretty sure every other article on this post I’ve read fully.)

Of course, my favorite article since college: How to Create Wealth

One of my favorite blogs with an interesting topic and high signal post here. Perhaps a bit verbose.

From the same blog, this article parallels some thoughts that I have had recently on children and creating products. Perhaps more about this another time or in person.

And one more for good measure: how to train yourself to spot opportunities

Of course, here’s a passionate article on a similar subject. I seriously think this article is epic.

Simplification and technology

Browser adoption politics article

Detailed analysis of sales of an indie BlackBerry app, over time.

For the statistics / math buffs, apparently you can algorithmically get a totally fair result from a biased coin.

Chris Baggott chronicling his efforts at making a low-effort product blog. Seems replicatable, although I’m not sure of the value produced.

I’ve been here, unfortunately.

How to make a difference in your field: Hamming’s You and Your Research

Some great reading by Seth Godin (probably second to Paul Graham as my favorite blogger). I am usually brimming with ideas after reading stuff like this:
http://sethgodin.typepad.com/seths_blog/2009/08/the-bandwidth-sync-correlation-thats-worth-thinking-about.html
http://sethgodin.typepad.com/seths_blog/2009/09/organizing-customers.html
http://sethgodin.typepad.com/seths_blog/2009/06/textbook-rant.html
http://sethgodin.typepad.com/seths_blog/2009/02/grave-new-world.html
http://sethgodin.typepad.com/seths_blog/2009/01/beauty-as-a-sig.html
http://sethgodin.typepad.com/seths_blog/2009/01/in-the-mood.html
http://sethgodin.typepad.com/seths_blog/2008/12/the-making-chas.html
http://sethgodin.typepad.com/seths_blog/2008/11/do-you-know-eno.html
http://sethgodin.typepad.com/seths_blog/2008/11/blah-blah-blah.html

I’m interested in this blog which combines biology and computer science to a degree. He is interested in open-source biology as well, which is a pretty interesting variation on a theme with many different things to consider. Here’s an interesting post.

More biology + computers

One of the more interesting papers I have read. Basically describes the “winner’s curse” (entity that wins auction likely overpays for item) as it applies to winning software contracting bids (winning entity most likely underbids, in this case, causing ruin in the near future.)

I’d say the same things that make student software projects succeed or fail can probably be applied to software contracting.

Martin Fowler on more readable regular expressions

Exciting applications of Erlang

If you’re on the hunt for something to use your newest shiny tool on or have some interesting algorithmic ideas, you could do worse than messing with these data sets.

And I can finally sleep at night because I don’t need to know everything about cars.

The paradigm shift that most people in software have seen coming for awhile. http://www.shirky.com/weblog/2009/03/newspapers-and-thinking-the-unthinkable/

If you need a kick in the ass or some passion:
http://www.seoblackhat.com/2007/01/29/do-it-fucking-now/
http://weblog.raganwald.com/2004/07/if-you-want-to-write-software.html
Quite NSFW, but pretty interesting
http://www.stevepavlina.com/articles/do-it-now.htm
http://www.37signals.com/svn/posts/1437-put-a-dent-in-the-universe
http://weblog.raganwald.com/2004/07/how-to-write-software-with-art.html
http://www.youtube.com/watch?v=Cbk980jV7Ao
http://www.slash7.com/articles/2009/1/25/quick-note-about-shipping
http://www.37signals.com/svn/posts/1626-the-most-powerful-word-is-no

My twitter statuses with links that are still useful:
http://twitter.com/panozzaj/status/4134727472
http://twitter.com/panozzaj/status/4080359840
http://twitter.com/panozzaj/status/3458258161
http://twitter.com/panozzaj/status/3430020800
http://twitter.com/panozzaj/status/2344419495

Original article: Interesting Links, Nascent Thoughts

The first two articles are here:  Part 1   Part 2

Original article: iPhone Tech Talks: Part 3 – Libraries and Performance

We’ve posted the 2009 schedule for the Indianapolis Workshops on Software Testing. We’re looking for people willing to share experience reports and people who just have a general interest in the various topics and would like to attend and ask questions.

Here’s a summary of the lineup:

February 26, 2009: Presenting test results

March 27, 2009: Test-driven development

June 27, 2009: Test design and development

August 28, 2009: Testing mobile devices

September 26, 2009: Automation and performance logging

October 29, 2009: Time management for testers

November 21, 2009: Managing your focus while doing exploratory testing

If you’re interested in attending any of the workshops, please drop me a line at mike@michaeldkelly.com.

I sent him an email saying that I would be interested in the March and October sessions. Perhaps you have some interest in the same/other sessions?

Original article: Testing Seminars