In my work, I come across a lot of great startups. A common question I get asked is "do you know someone amazing that we can hire?" Similarly, I get pinged by many colleagues, friends, and fans who are looking to find a job with a startup. I do my best to play matchmaker, but as those of you who have ever tried to fill a job in a startup know, the most important and elusive quality for a startup hire is fit. Unfortunately, as any good recruiter will tell you, this is not an easy thing to assess as an outsider.

So I used to wind up spending a lot of fruitless hours trying to play matchmaker, and generally having a hard time. Part of the problem is that I couldn't post a public link. Most of the jobs I come across are not listed in any directory, and most of the candidates are not officially looking - many don't even have a resume. Great startups are always hiring, if the fit is right. They may not have an open req for a specific job, but if the right amazing person walks in the door, they will always find something productive for them to do.

To solve this problem, I asked a friend to collaborate with me in building a new tool. It's incredibly simple, and it's called joblink.tw. Think of it as a bit.ly for jobs. Using it to recruit takes less than a minute.

joblink.tw lets you post a description of a job without having to reveal the name of the company who is offering it, or the contact information of the hiring manager. Who wants that stuff posted on the internet? Instead, each joblink has a form that allows anyone who's interested to contact the poster. The actual exchange of information occurs in private, in email.

The same process works for job candidates. Know someone who'd make a great engineer at a startup? Just write a few words about them, set their email address as the private recipient, and tweet about it. They can turn off these contacts at any time.

To see a list of the jobs that I've posted on joblink.tw so far, take a look at my joblink profile. joblink.tw also supports oauth, so you can log in with your twitter credentials. If you do, you can have your joblinks broadcast on the joblinktw twitter account. For updates about joblink.tw or to see joblinks that others have posted, follow on twitter.

So far, this tool has saved me countless hours, and made quite a few interesting connections. That means it's accomplished all of my goals for it. If anyone else finds it useful, too, that will prove a huge plus. And if anyone has feedback, please feel free to use our integrated uservoice forum or just post a comment on this post. I'd be happy to make it better (regular readers will recognize joblink as a minimum viable product).

I'm very excited to announce a pair of events that will kick off a very busy fall speaking tour. I'll be in Boulder for two days. I'll let David Cohen of Techstars, who organized the trip, describe the plan:

On August 19th, Eric will be speaking at a dinner in Boulder. The event will include a talk from Eric on The Lean Startup over dinner, followed by moderated table discussion and then final Q&A with Eric. Tickets are available now and include dinner. A discounted price is available for early stage entrepreneurs and students.

On August 20th, Eric is leading a half day in-depth workshop on the Lean Startup. This is a great chance to really go deep on some of the concepts behind building Lean Startups. A very limited number of tickets are also available for this workshop. Early bird pricing expires on August 6th, so register early.

Traveling to new startup hubs is one of my favorite things about being able to do this full-time. I want to thank Techstars for putting this event together and giving me a chance to experience the scene, even if it lacks a name. For what it's worth, I like Silicon Mountain.

Brad Feld also had some thoughts on this event on his blog. I thought I'd share a little bit of that, too:

I’ve been interested in different approaches to software development going back to 1987 when – in my first company Feld Technologies – my partner Dave Jilk and I started talking about “semi-custom software development” (way ahead of its time). During the same period (1987 – 1990) and I did some work at MIT under Eric von Hippel on “user driven innovation with regard to software development” which today would probably fall under the heading of “open source software development approaches.”

In 2002 I became exposed to the idea of “agile software development” and subsequently was a first round investor in Rally Software which is now the market leader in Agile application lifecycle management software. Building on this, I’ve recently become fascinated with the notion of continuous deployment, a concept that has been popularized by Eric Ries and others.

Read the rest...

And for those of you who are in Colorado but don't know what my speaking events are like, please take a look at some previous posts. We've got slides, video, audio and twitter commentary. That way, you can know what you're in for in advance.

As usual, if you're a reader and can attend, please come say hello. Thanks!

(Speaking of the fall tour, if you're interested in hosting or organizing a lean startup event near you, feel free to drop me a line. So far, I'm going to be on the east coast at least three times, and in Europe twice. Stay tuned for more details.)

Homeless Man Builds 5mln Dollar Website

Financial debt plays an important and positive role in our economy under normal conditions. Yet, especially in times like these, it’s easy to rail against the badness of being in debt; it’s a very human feeling. Remember Hamlet?

LORD POLONIUS:
Neither a borrower nor a lender be;
For loan oft loses both itself and friend,
And borrowing dulls the edge of husbandry.

Technical debt works the same way, and has the same perils. Here’s one of my favorite introductions to the subject, courtesy of Martin Fowler:

In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The human tendency to moralize about debt affects engineers, too. Many conclude that technical debt is a bad thing, and that teams that incur technical debt are sloppy, irresponsible or stupid.

In this post, I want to challenge that idea, by talking about real-world situations where debt is highly valuable. I hope to show why lean and agile techniques actually reduce the negative impacts of technical debt and increase our ability to take advantage of its positive effects. As usual, this will require a little theory and a willingness to move beyond the false dichotomy of “all or nothing” thinking.

I won’t pretend that there aren’t teams that take on technical debt for bad reasons. Many legacy projects become completely swamped servicing the debt caused by past mistakes. But there is more to technical debt than just the interest payments that come due. Startups especially can benefit by using technical debt to experiment, invest in process, and increase their product development leverage.

In a startup, we should take full advantage of our options, even if they feel dirty or riddled with technical debt. Those moralizing feelings are not always reliable. In particular, try these three things:

Invest in technical debts that may never come due.
The biggest source of waste in new product development is building something that nobody wants. This is a sad outcome which we should work very hard to avoid. Yet there is one silver lining when it does happen: we wind up throwing out working code, debt-riddled and elegantly designed alike. This happened quite often in the early days of IMVU.

For example, I’ve talked often about our belief that an instant messaging add-on product would allow IMVU to take advantage of a network effects strategy. Unfortunately, customers hated that initial product. The thousands of lines of code that made that feature work were a mixed bag – some elegantly designed and under great test coverage, others a series of hacks. The failure of the feature had nothing to do with the quality of the code. As a result, many technical debts were summarily cancelled. Had we taken longer to get that feedback by insisting on writing cleaner code, the debt would have been much deeper.

Accept that good design sometimes leads to technical debt anyway.
Discussions of technical debt are usually framed this way (again from Martin Fowler):

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline.

This framing takes for granted that the quick and dirty approach will incur significantly more technical debt than the slow and clean approach. Yet other agile principles suggest the opposite, as in YAGNI and DoTheSimplestThingThatCouldPossiblyWork. Reconciling these principles requires a little humility.

Most of us think we know a good design when we see it. Unfortunately, no matter how much up-front analysis we do, until the design is tested by actual practice, we can't really know. Outside the world of hypothetical examples, it's more important to make continual progress than to build the ultimate design.

For example, at a previous virtual world company, we spent years developing an architecture to cope with millions of simultaneous users. Unfortunately, we made two critically flawed assumptions: that customers would primarily consume first-party assets that we shipped to them on CD and that they would tend to congregate in a relatively uniform way. Neither assumption proved remotely accurate. The design failure meant that there was constant thrashing as the servers struggled to provision capacity according to the “elegant” algorithm we’d designed.

As in many scalability decisions, we’d have been much better off investing in agility, so that we could change the architecture in response to actual customer demand, rather than trying to predict the future. That’s what Just-in-time Scalability is all about. Sometimes quick and dirty actually incurs less debt.

Leverage product development with open source and third parties.
Financial leverage refers to investing that is supplemented by borrowed money. Similarly, product development leverage refers to situations in which our own work is fortified by the work of outsiders. For example, early on at IMVU, we incorporated in tons of open source projects. This was a huge win (and we were delighted to give credit where it was due), because it allowed our initial products to get to market much faster. The downside was that we had to combine dozens of projects whose internal architectures, coding styles, and general quality varied widely. It took us a long time to pay off all the debt that incurred – but it was worth it.

In addition, third-party services and API’s enabled us to do more with less, but at a cost: taking on the technical debt of products and teams outside our direct control. We’re not accustomed to accounting for technical debt that occurs in code that we don’t write, but this is short sighted. It’s important to learn to see the whole system that makes our product work: human as well as machine, internal as well as external.

For example, IMVU’s early business model was made possible by Paypal’s easy self-serve and open access payment system. However, we’ve often had to put up with unreliable service, caused by their inflexible internal architecture. We had to live with their technical debts without being able to repay them. It was still a good trade.

Not all debts are created equal.
Interest rates vary, so we should be selective about taking on new debts. Given the choice between incurring technical debt in a particular end-user-visible feature and incurring the same level of debt in a core system, I’d much prefer the former. Here’s why:

• There’s a chance that I’ll never have to pay for that particular debt, because the feature may have no value for customers.
  
  
• It’s possible that the feature, even with debt, might be good enough, and therefore not need revision for a long time. Technical debt manifests as rigidity or inflexibility. When modifying a part of the product afflicted by debt, the work requires a lot of extra – and unpredictable – clean up. But if a given feature is rarely modified, its debt is much less expensive.

The opposite is true with debt in a core system; it’s much more likely that this debt will slow down our ability to make changes later on. For example, an unreliable library deep in the core will manifest as intermittent defects all throughout the product, each of which is hard to localize and debug. Side-effects that reduce agility are the most damaging symptoms of technical debt.

Lean vs. debt
In the world of physical goods, the leaner a supply chain is, the less debt is required to operate it. This makes lean supply chains more robust in the face of the unexpected: if sales suddenly dry up, they are stuck with less unsold inventory and simultaneously have less debt to service. The just-in-time nature of the value chain reduces risk in the face of uncertainty and is also more capital efficient.

A similar relationship applies to technical debt. Teams that practice an agile or lean development process are able to minimize the accumulation of technical debt without sacrificing speed, because they work in smaller batches. They also take better advantage of debt, because they find out sooner if a particular investment has paid off. Traditional development teams, by contrast, often build and deploy large systems before learning if their early choices were sensible, and therefore wind up with a much larger debt to pay. In fact, by the time they become aware of it, they’ve already started to pay significant interest on that debt.

Invest in speed instead of features or debt
This relationship between lean and debt opens up new approaches for dealing with technical debt. The usual debate is phrased as an either-or choice between taking more time to “build it right” or taking a shortcut and incurring more debt. But those are not our only two options. Taking on technical debt does allow investing energy elsewhere, but other new features are not the only option.

We can trade technical debt for process improvement, too. If that improvement pays off (by reducing the batch size of our work, for example), it becomes easier to address all technical debt in the future – including the debt just incurred. And because any particular debt might never come due, this is a better trade. To take one concrete example, it’s often worthwhile to write test coverage for legacy code even without taking the time to refactor.

This reverses the standard intuition about what engineering activities add value, which usually concludes that test coverage is a form of necessary waste but a refactoring is value-added work. However, a refactoring (by itself) might go stale or introduce unintended side-effects. Adding test coverage will make it easier to refactor in the future and also reduce our fear of making changes elsewhere.

Investing in the dynamics of development is more valuable than investing in the static status quo. Startups are always moving, so invest in moving faster and better.

Technical debt in the real world
So far, all of these considerations have been framed in the form of abstract either-or tradeoffs. Real life seldom presents such comparable choices. Instead, we balance lots of unknowns. How much technical debt will a particular approach incur? How likely will customers ultimately use that feature? How painful will it be to refactor later? How much will it slow us down in the meantime? And how much more expensive would it be to do it right? Oh, and how likely is it that the “right” approach actually is?

Luckily, there are better options for these complex decisions than picking an easy extreme, like “never incur technical debt” or “anything goes.” Instead, we can choose a disciplined approach to making proportional investments in prevention and paying down debt, such as Five Whys. They work by focusing our energy on making process and technical changes in precisely those areas that are causing the biggest waste and slowdown.

This is better than making abstract choices about where to invest: better design, paying down old debts, or better process. Instead, techniques like Five Whys teach us to view the entire application and product development team as one integrated system. From this holistic viewpoint, we can optimize accordingly.

Once we can see opportunities for truly global efficiency gains, all that remains is to ensure our team actually makes room for those investments. To do that, we add specific speed regulators, like integrating source control with our continuous integration server or the more elaborate dance required for continuous deployment. This produces a powerful combination: the speed of just-in-time experimentation wedded to a discipline of rigorous waste-reduction.

One last thought. When I talk and write about the advanced product development process at IMVU today, like the cluster immune system or the disciplined approach we take to split-testing and interaction design, it may sound as if we had that capability from the start. Nothing could be further from the truth. The early IMVU was riddled with legacy code and technical debt. We spent endless hours arguing about whether we’d made the right choices in the past. And with the benefit of hindsight, it’s clear that we often made serious mistakes. As one engineer recently told me, “Once we had money in the bank and were near-profitable, I think we would have been well-served by increased up-front product and technology planning. As a culture, we hadn’t yet learned how to make long-term decisions.” He’s right.

In the end, what mattered wasn’t that we did everything right, but that our fundamental approach was flexible and resilient. At no point did we stop everything and do a ground-up rewrite. Instead, we incrementally improved our process, architecture, and infrastructure, always learning and adjusting. The blur you see today is the result of the beneficial compounding interest of that approach applied with discipline over many years. Trust me, it’s a lot of fun.

(This post was tremendously enhanced by a number of early readers from the Twitterverse. You know who you are. Thanks so much.)

Hello from Long Lane Honey Bee Farms, and welcome to today's lesson in Beekeeping on hygienic behavior and testing for mites using a powder sugar roll.

But before we get started, let me say thank you to so many of you who email us or call in and offer kind words and thank us for providing these free online lessons. We hope our efforts are making a dent in the beekeeping community in helping more people get started keeping bees as well as beekeepers becoming more successful.

I recently removed a colony of honeybees from a home in Campaign, Illinois and the TV crew came out and put it on the news. Click here to what the news video.
If you are so moved to help support these free online lessons with a donation, we would appreciate it. Think of the money would would have to pay to purchase books or CDs to receive the same information. So your donation, no matter how small, will go far to assist us in keeping these lessons going out. If you do wish to donate, we thank you in advance, and encourage you to send your check to: Long Lane Honey Bee Farms, 14556 N. 1020 E., Fairmount, IL 61841 or you can donate via paypal or credit card by clicking on the link below.





LESSON: 58: HYGIENIC BEHAVIOR TRAITS & HOW TO TEST FOR MITES USING A SUGAR ROLL
Sunday, our local beekeeping club, of which I am president of, met at our honey bee farm in the afternoon. Dr. Stu Jacobson was our guest speaker. Dr. Jacobson spoke on the importance of raising and providing beekeepers with hygienic queens, bees that can detect reproducing mites and some disease below sealed brood, and carry it outside the hive before it has time to spread and cause problems.
In Lesson 45, I explained more of the details and history behind using hygienic bees, but for today we will examine more about performing the test and evaluating the results.
TESTING A HIVE FOR HYGIENIC BEHAVIOR
I'll make comments under each picture below walking you through the process. The liquid nitrogen is very cold and therefore, must be handled with care. Protective clothing and eye wear is a must to against accidental spillage. Please be careful. Liquid nitrogen can be purchased from most welding supply shops.


First, select a frame of sealed brood from one of your hives that you want to test. Make sure to choose a frame where most cells are sealed. (Images in this lesson can be enlarged by clicking on the image)
Shake the bees off and push a 3 inch diameter can down into the comb until it reaches the middle of the comb. Keep track of how many cells are not sealed. In this case, there are 18 unsealed cells within the inside of the can area.
Pour in 2 ounces of LN to prime the area. Then, pour in about 7 ounces to freeze kill the brood within the can.


Here, Dr. Jacobson demonstrates how to pour the LN, using tongs and a paper cup.
Now that the brood is killed, place the frame back in the hive and wait 24 hours. Then, pull out the same frame. If they show hygienic behavior, the dead brood will all be removed.
As in this picture you can see the circle where the brood has been cleaned out. It is not a perfect circle at the bottom due to some of the LN spilling out on to the adjacent area. This is an hygienic hive.
If we are to move away from over medicating our hives, we must make these efforts to tap into the bee's own defense against pests and diseases.
Next, Dr. Jacobson demonstrated how to conduct a varrora mite test on your hive. This will be very helpful for those of you who are concerned about v. mites. Dr. Jacobson supports what I've said for years about how the mite drop count method may not give accurate readings. In other words, if bees are good at picking the mites off and dropping them, they may have less mites on the bees but the drop board might show alot.
A better method is to capture 200 bees in a small jar with a screen lid. Put in several spoonfuls of powder sugar and roll the bees around in the powder sugar. The mites can no longer cling to the bees due to the sugar and you then shake the jar so that the mites fall though the top screen.
In our test, we used a paper plate to shake out the mites. As a result of our study, about 3 mites were visible as noted in the photo below.

Some people use various chemicals to kill the bees and the mites stick to the side of the jar for counting. Chemicals like ether or starter fluid is often used. This works, but if you have accidentally shaken the queen into the jar, she will perish along with the bees. Therefore, powder sugar will not hurt the bees but allow the mites to drop off.

I want to take this time to encourage other local bee clubs to raise the educational bar higher within the meetings. Beekeepers will have greater success the more education on beekeeping they receive. Having guest speakers or well informed and experienced local beekeepers share at the meetings on predetermined topics can really help the beekeepers in your local club enjoy keeping bees.

In our club, we meet at a different member's home each time.

Also, be sensitive toward the new beekeeper who will feel intimidated by the more experienced beekeepers and their opinionated attitudes. We are opinionated. Try to encourage the more outspoken beekeepers to be more encouraging to the newer beekeepers.

Also, our club offers a list of mentor, a list of people who are willing to work along side new beekeepers.

That's it for today! We appreciate you joining us today!

Remember, register for our upcoming courses as soon as possible as these classes fill up fast!

BEE-have yourself!

David & Sheri Burns
Long Lane Honey Bee Farms

www.honeybeesonline.com

EMAIL: david@honeybeesonline.com

PHONE: 217-427-2678

Twitter: http://twitter.com/longlanehoney

I'm planning to be back...hopefully in August. Life for everyone is busy, I know. But here, I'm just taking a little extra time to enjoy this time that will go way too fast.

Hope you're having a great summer!

Melangkahi detik waktu dan ketika
Seakan-akan aku tertipu dengan dunia
Merasakan diri ini sudah cukup berusaha
Bersangka dengan dakwah yang tidak seberapa
Allah lalu mengizinkan pelajaranku juga berjaya
Sedangkan keadilan Allah tiada taranya
Segala andaian didahului Sunnatullahnya
Pepatah Arab Man Jadda Wajada
Sesiapa yang berusaha pasti mendapatkannya
Maka kembali aku terduduk teraba-raba
Mencari kembali rentak dan irama
Apakah diri sudah cukup berusaha
Apakah dakwah sudah ikhlas hanya keranaNya
Lalu kusedari diri ini sungguh hina
Kerana mengambil mudah ketetapannya
Berpangku tangan tanpa berusaha
Lalu mengharap kejayaan jatuh ke riba
Oh Allah, diriku alangkah malunya

Lalu kini aku bangkit kembali
Segala kisah silam aku lupai
Cuma menjadi sejarah yang abadi
Yang menjadi iktibar buat diri
Mengingatkan bahawa jalan ini tidak akan pernah sunyi
Daripada ujian keperitan dan serta onak duri
Tiada lagi bersenang-senang duduk menyendiri
Kutahu bahawa janji Allah itu pasti
Bahawa manusia hanya akan mendapatkan apa yang dikerjai
Lalu aku kembali melangkah dengan pasti
Matlamat hidup yang jelas telah kuletaki
Hanya ingin mendamba redha Ilahi
Dan semuanya sudah jelas dan pasti
Redha Allah tidak akan mendampingi si leka ini
Akan kususun atur hidupku ini
Agar kejayaan pasti kukecapi
Dunia dan akhirat akan kumiliki
Walau berapapun yang harus kulunasi

Oleh itu saksikan wahai Ilahi
Bahawa diri ini telah kembali!

Jihad Dakwah & Study!

Ya-Allah, jadikanlah semester baruku ini semester yang terbaik buat dakwah dan studyku!

Hello from Long Lane Honey Bee Farms, located in central Illinois! We are a husband and wife team operating a family beekeeping business and we love it! It is a blast not just because our hobby turned into a business, but because we enjoy being together and working together with our children. And, we enjoying helping the beekeeping community as well.





LESSON 56: QUEEN EXCLUDERS

What's the real story about queen excluders? Do they work? Do I recommend them? Will they cut down on your amount of honey? Why are there different kinds of queen excluders.

A queen excluder is a metal or plastic device which looks much like a metal shelf in your refrigerator. The metal ones are made up of small metal rails close enough together so that the queen cannot squeeze through but the workers can. Beekeepers use them below a honey super to prevent the queen from going up into the honey super and laying eggs. There is now a plastic queen excluder on the market that works just as well.

PROS & CONS

PROS: The queen is excluded.


CONS: The queen is not always excluded. A small queen can sometimes squeeze. Drones get stuck. The bees often place stray comb between the openings. It does seem to slow down the progress of the bees filling the super above it. It's another high maintenance item.

TIP #1: Never use a queen excluder below a honey super that has undrawn comb. Make sure your comb is drawn out first. It is sometimes a challenge to get the frames drawn out by the bees on honey supers. A queen excluder can make it more restrictive and it can take longer. So do not place it on until the super frames are somewhat drawn out.
TIP #2: The metal queen excluder has support wire beneath the main row of wire. Those support cross bars should always face the brood nest area. This will prevent the queen from slipping through the wires.

So when you've placed it above the brood nest correctly, the wires will run the same direction as the frames below, and you can rub your hand across the queen excluder without feeling the cross bars. They will be on the bottom side of the queen excluder, running the opposite direction as the frames. We do this because when a queen tries to squeeze through she will slide along the wire, but when she hits a cross wire, she cannot continue to try to work through.

Some beekeepers are so opposed to queen excluders they call them "honey excluders". Indeed, they can restrict the passage of foraging and transport bees, and clogged with drones and wax, the passageway is even more restrictive.

MY OPINION AND APPROACH

For a new beekeeper, a queen excluder can be a big help. However, I do not use queen excluders. Instead, I monitor my queen and if I see her in the upper super, I pick her up and move her back down into the deep hive bodies.

The queen will not lay in a cell that has honey in it. So, my goal (and the bees) is to place honey in the super before she gets up there to lay, forming a honey barrier. So that is also why I like to "top super" which means I add empty supers on top of supers the bees are already filling. I don't have to worry about the queen going beyond the honey barrier.

I've noticed that if I give the queen plenty of room in her brood nest, the lower two deep hive bodies, then she rarely gets up into my supers. If she does, she lays just a small amount of eggs in the center frames and only toward the very lower bottom part of the frame. So I wait and let the brood hatch, then the bees clean up the cells and finish filling it with nectar and curing it into honey and sealing it off.

Thanks for joining us for today's lesson and I hope this has been helpful for you. Remember, we are here to help you succeed as a beekeeper. Please feel free to call us for supplies or equipment you might need. We also raise our own queens, so call us if you need to replace your queen.


Or call us for any beekeeping need you have: 217-427-2678
Visit us online at: www.honeybeesonline.com
Follow us on Twitter: http://twitter.com/longlanehoney
And check us out on Facebook too!
EMAIL: david@honeybeesonline.com

Until next time, remember to Bee-Have Yourself!
David & Sheri Burns
Long Lane Honey Bee Farms

Hello From Long Lane Honey Bee Farms! We are David & Sheri Burns and we are passionate about beekeeping. We started out keeping bees as a hobby and the hobby went wild.

For us, beekeeping is a blast. If you are not a beekeeper, we hope you'll peruse through our beekeeping lessons and consider becoming a beekeeper.

If you are considering becoming a beekeeper next year, then now is the time to prepare. It may seem like a ways off, but not really.  This will give plenty of time for first time beekeepers to study our lessons, purchase equipment and decide on the best location for the placement of your hives.

So, my nose is glue in books every spare moment I have. My head is spinning with bee knowledge.

We've added two new features to our web presence:

http://twitter.com/longlanehoney So you can follow us as we tweet and we now are on facebook too.

LESSON 56: COMMON QUESTIONS ADDRESSED We receive so many questions from beekeepers around the world. I decided to use recent questions as this lesson. Hopefully my answers will help you as a beekeeper, afterall we all have the same kinds of questions, don't we.

And I've just thrown in random beekeeping pictures for your enjoyment.

Q... When I observed my queen moving around, I noticed she just walks around a lot and does not continuously lay eggs. Even when I think she lays an egg after looking into a cell, her abdomen does not fully immerse into the cell but she just places her abdomen at the top of the cell and she does a wiggle and goes away. I also thought that the queen measures the cell with her hind legs and then lays but I noticed she was going in head first. I do not understand what she is doing. Is this a common behavior?

A... Thanks for your questions. Let me correct you. Queens measure cells with the front legs, that's why we always hold the back legs when marking queens. If a front leg breaks off, then she will only be a drone layer. She does look head first into a cell and then moves slightly forward and rotates her abdomen into the cell to lay an egg. Sounds to me like you might have a virgin queen or a newly mated queen or a mated queen that has just been released from her cage. Give her a week and see if she doesn't work more efficiently.

Q... Hi Dave! What do you place your bottom boards on? I have mine on precast concrete patio 24” square pavers then one brick in each corner of the bottom board to allow for air flow. I have received advice from an old beekeeper that open bottom boards are bad for overwintering. Just curious. Thanks.-Herman

A... Hi Herman Hi Herman, I agree with the experienced beekeeper IF the screen bottom boards do not have some sort of shielding around them to break the wind. But, I have found the open bottom to be very helpful for getting rid of excessive winter condensation moisture from the hive.I just have mine sitting on pallets.

Q...Good afternoon, Mr. Burns - First, thanks for taking the time to write your lessons blog - you're doing more than anyone else I've seen out there on the Net to assist beginning beekeepers with their questions. It's also a great portal to your apiary website; hopefully, you're being rewarded with increased business. I had a quick question for you: I didn't see anywhere on your site a mention of which race(s) of bees you sell. I'm looking for a regular supplier of Carniolan queens (preferably Old World, but New World as well). Don't suppose you deal with these? Thanks, Mark

A... Thanks Mark for your kind comments. Carniolans are the bee of choice for us. However, we also concentrate more on characteristics than race. We open air mate our queens as well in a somewhat controlled area. So the queens that we raise do tend to show more Carniolan characteristics. We also purchase Carniolan breeder queens that we graft from.

Q... Hi David & Sheri my is Dan Richards i live in a small area called Rusagonis NB Canada I love your site yes we have a small Beekeepers Assn Keep up the great work I have passed your site to members of our assn. I am checking out the laws regarding getting Queens from USA . Thanks again. Dan

A... Thanks Dan! Nice to meet you!

Q... How do you mail queens? Have you had success in using the plastic cages with attendants included? It seems quite small and the access to candy limited. I was going to try to avoid the expense of the three-chambered wood cages. I bank queens in plastic and would like to find a way of mailing them that way. Larry

A... Hi Larry, I exclusively use the California Mini Cage that is made by Koehnen. http://www.koehnen.com/cmq.html I have the best all around success in the following areas with this cage: --Transportation --Protection against mandibles of bees that are initially unaccepting. --Ability for bees to feed queen through the cage. --Ease of inserting candy plug. --Smaller size fits easily between frames. We are rotating queens through about 50 mating stations. So I am able to produce about 15 acceptable queens per week. I try not to bank virgin or mated queens unless I have to. It is better to bank layers than virgins. Virgins banked longer than 3 weeks will be no good. Virgin queens are tough to be accepted, so we place capped queen cells into queenless mating stations, let them prove they can lay well for a few weeks, evaluate their daughters and sell.

Q... Hi David,
I have been beekeeping for 5 years and this year is the first year I have ever extracted honey from my bees. I'm so excited! Today I peeked in my 5 gallon bucket to see how the bubbles were rising and it smelled a little like beer. I'm concerned its fermenting. All the frames were capped, 100% of them, my equipment was dry too, is this aroma normal? and if not what do I do?

Thanks so much for your time,
Nadina

A... It might be normal, but then again, normally honey doesn't smell as if it is fermenting. Sometimes, capped honey can still have too high of a moisture level. I recommend always using a refractometer to take samples. I keep my honey room below 39% humidity and I always air out my sealed honey for several days with a fan on it before I process it. If it tastes like it has fermented, then it has and is not fit to sell. A slight fermentation smell may just be that the bubbles have risen to the top and the honey below is fine. See if you can taste the honey atleast a few inches below the surface.

Also, check out my lesson 12: http://basicbeekeeping.blogspot.com/2007/10/lesson-twelve-moisture-level-of-honey.html

Q... Dear David,
I was wondering if your package bees are still available for shipment? I live in Arizona. Thank you for your help. Sincerely,Marcy

A... Sorry Marcy, all so out. Packages must be purchased very early in the year. Always call your package bee orders in as soon as you can in January or February, March at the very latest.

Q... Hi David, I'm just starting in beekeeping in New Zealand, purchased two occupied hives from retiring beekeeper and I've found your online lessons fantastic .. I really appreciate not just the what to do, but also the information about why to do it that you have put in them.
One thing I'm trying to work out is to do with inspections. It seems like I need a sunny, wind free day and a temperature really needs to be above 60F, and that ideally I should do this every couple of weeks.. but of course it is the middle of winter here, and that means the temperature typically won't get above 50F. I guess beekeepers are always having to compromise on this sort of thing. Do you have any recommendations on a winter inspection programme?
Thanks again for all the wonderful insights from your lessons.
Chris

A... Good question. Please check out my lesson 28 http://basicbeekeeping.blogspot.com/2008/03/lesson-28-spring-management-of.html

But basically, wait until the warmest day possible, maybe upper 30s or 40s (f) or 50s is better, and just briefly open up the hive to peek and make sure there is plenty of stored honey next to the cluster. Do not lift out frames with bees. You can move frames of stored honey if you want to, but remember some bees might fly out and let you know they are not happy about you opening up their hive. They may also die from the cold as well. So work fast.

Q... Hey David
I just read your lesson on swarms and I have to say I am impressed. I am a new beekeeper this year and have only 3 hives (WBC because we are English). I attended a 3 month course before starting and I gained more from your lesson than on the course. Keep it up, the bees need you.
Regards
Gary

A... Thanks Gary

Q...Hello David,

I have really enjoyed your beekeeping lessons online. I was hoping you could give me an answer to two questions:

1. In one of your lessons you stated that a virgin queen may fly several miles to get mated or at least a long distance. If a queen breeder is advertising a certain breed of queens how can he tell for sure that the queen was mated like he thinks. Let’s say that a queen breeder was advertising in a Bee magazine that he was selling pure Russian queens. How does he know that his virgin queen was fertilized by a Russian male bee if down the road a mile was a bee yard full of Italian bees??

2. I noticed in your pictures that you use a lot of double brood chambers. Can you tell me what you are doing here?
Best Regards,
Charlie

A...Hi Charlie, Good point. Lots of claims made that can really never be tested
by the buying beekeeper. You only want an open air mated queen,
as they do better and lay longer than inseminated queens. Only
through Instrumental Insemination can a queen breeder make
claims of purity of progeny.

Now, you can do a lot to control purity even in open air mating.
For example, there is not a large beekeeper near us, so we
can “flood” the area with the genes we want, and so we can
control it quite nicely, but we would never make a claim of purity.

We use two deeps so that the bees can over winter with plenty
of honey on board.

Q...David, Hope things are going well with you & your family. I know you are busy, but I have a question. I installed my package on 5/1/09 when they arrived. About how long should it take for a package to draw out enough comb to add a second deep? I check my bees every 2 weeks like you suggested, and they have drawn out about 5-6 frames. Is it normal for them to take this long? I am concerned that they may not have enough store to take them through the winter. Have any thoughts that may help me?

Thanks for all your help.

Tim

A...Hi Tim, this is every beekeeper's concern. A package of bees actually drops down a little in number after they are installed, but finally once the queen becomes adjusted to the bees, the hive takes off. How well they do depends on several factors outside the beekeeper's control such as the weather and the nectar flow. Typically we hope a package can fill up the bottom deep in about 6 weeks, and the same on the second deep. Sometimes it is faster, and usually slower. I like to "bait" the second deep, by pulling out a few frames from the lower deep hive body with brood and bees, and place them in the upper deep next to the undrawn comb. This lures the bees to move up into my second deep. Two frames is usually plenty. I have also noticed that we as beekeepers have much higher expectations from our bees than what is often practical. So be patient.

Well, I hope you've enjoyed alittle Q&A today. Our family hopes that your beekeeping season goes well. Please keep an eye on your queens. Remember to always operate your hives with a young, prolific queen. Don't take a chance and go into winter with an old or poor laying queen. Call us if you need to replace your queen. 217-427-2678.

Also, we continue to make improvement on our hive equipment that we build. If you are in need of additional hive or hive components, give us a call at 217-427-2678. We also sell all beekeeping equipment. And feel free to allow us to become your mentor in beekeeping!

Until next time remember to BEE-have yourself!

David & Sheri Burns

Long Lane Honey Bee Farms

http://www.honeybeesonline.com/

217-427-2678

If you've ever wondered why agile or lean development techniques work,The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen is the book for you. It's quite simply the most advanced product development book you can buy.


For those who hunger for a rigorous approach to managing product development, Donald Reinertsen's book is epic. Myths are busted on practically every page, even myths that are associated with lean/agile. For example, take the lean dictum of working in small batches. I push this technique quite often, because traditional product development tends to work in batches that are much too large. Yet it's not correct to say that batch sizes should be as small as possible. Reinertsen explains how to calculate the optimal batch size from an economic point of view, math and all. It's wonderful to have an author take these sorts of questions seriously, instead of issuing yet another polemic.

The book is structured as a series of principles, logically laid out and briefly discussed - 175 in all. It moves at a rapid clip, each argument backed up with the relevant math and equations: marginal profit, Little's law, Markov processes, probability theory, you name it. This is not for the faint of heart.

The use of economic theory to justify decisions is a recurring theme of the book. Its goal is to help us recognize that every artifact of our product development process is really just a proxy variable. Everything: schedules, efficiency, throughput, even quality. In order to trade them off against each other, we have to convert their impact into economic terms. They are all proxies for our real goal, maximizing an economic variable like profit or revenue.Therefore, in order to maximize the true productivity (aka profitability) of our development efforts, we need to understand the relationships between these proxy variables.

Just for the economic explanations, this book would be worth the price of admission. But it goes beyond that, including techniques for improving the economics of product development. Reinertsen weaves together ideas from lean manufacturing, maneuver warfare, queuing theory, and even the architecture of computer operating systems and the Internet. It's refreshing to see ideas from these different domains brought together in a coherent way:

If we limit ourselves to the relatively simple WIP [work-in-progress] constraints used in lean manufacturing, we will underexploit the power of WIP constraints. Instead, we will explore some of the more advanced ideas used in the world of telecommunications.

If we showed the Toyota Production System to an Internet protocol engineer, it is likely that he would remark, "That is a tail-dropping FIFO queue. That is what we started with on the Internet 30 years ago. We are now four generations beyond that method." I mention this to encourage you to look beyond the manufacturing domain for approaches to control flow.

Reinertsen is keenly aware of what makes product development different from other business functions, like manufacturing, that we sometimes use as a metaphor. Product development deals in designs, which are fundamentally intangible. This is why product development routinely creates disruptive innovation, because our ability to invent new products is limited only (well, primarily) by our capacity for imagination. And yet it is this same ephemeral nature that gives rise to the most difficult problems of product development: how to tell if we're making progress, the high variability of most product development tasks (e.g. will this bug take 5 minutes or 5 weeks to fix?), and the resulting extreme uncertainty that is, incidentally, the environment where startups thrive.

To motivate you to buy this book, I want to walk you through some of Reinertsen's indictment of the status quo in product development, which is based on his extensive interviews, surveys, and consulting work. He starts the book with twelve cardinal sins. See if any of these sound familiar:

1. Failure to correctly quantify economics.
2. Blindness to queues.
3. Worship of efficiency.
4. Hostility to variability.
5. Worship of conformance.
6. Institutionalization of large batch sizes.
7. Underutilization of cadence.
8. Managing timelines instead of queues.
9. Absence of WIP constraints.
10. Inflexibility.
11. Noneconomic flow control.
12. Centralized control.

Reinertsen is not pulling punches. For example, here's him discussing our collective blindness to queues:

To understand the economic cost of queues, product developers must be able to answer two questions. First, how big are our queues? Today, only 2 percent of product developers measure queues. Second, what is the cost of these queues? To answer this second question, we must determine how queue size translates into delay cost, which requires knowing the cost of delay. Today, only 15 percent of product developers know the cost of delay. Since few companies can answer both questions, it should be no surprise that queues are managed poorly today.

Or take this indictment of our worship of efficiency:

But, what do you product developers pay attention to? Today's developers incorrectly try to maximize efficiency ... Any subprocess within product development can be viewed in economic terms. The total cost of the subprocess is composed of its cost of capacity and the delay cost associated with its cycle time. If we are blind to queues, we won't know the delay cost, and we will only be aware of the cost of capacity. Then, if we seek to minimize total cost, we will only focus on the portion we can see, the efficient use of capacity.

This explains why today's product developers assume that efficiency is desirable, and that inefficiency is an undesirable form of waste. This leads them to load their porcesses to dangerously high levels of utilization. How high? Executives coming to my product development classes report operating at 98.5 percent utilization in the precourse surveys. What will this do? [This book] will explain why large queues form when processes with variability are operated at high levels of capacity utilization.

Or consider principle B9: The Batch Size Death Spiral Principle: Large batches lead to even larger batches:

The damage done by large batches can become regenerative when a large batch project starts to acquire a life of its own. It becomes a death march where all participants know they are doomed, but no one has the power to stop. After all, when upper management has been told a project will succeed for 4 years, it is very hard for anyone in middle management to stand up and reverse this forecast...

Our problems grow even bigger when a large project attains the status of the project that cannot afford to fail. Under such conditions, management will almost automatically support anything that appears to help the "golden" project. After all, they want to do everything in their power to eliminate all excuses for failure.

Have you had trouble buying a new piece of test equipment? Just show it will benefit the "golden" project and you will get approval. Have a feature that nobody would let you implement? Find a way to get it into the requirements of the "golden" projec. These large projects act as magnets attracting additional cost, scope, and risk...

At the same time, large batches encourage even larger batches. For example, large test packages bundle many tests together and grow in importance with increasing size. As importance grows, such test packages get even higher priority. If engineers want their personal tests to get high priority, their best strategy is to add them to this large, high-priority test package. Of course, this then makes the package even larger and of higher priority.

This snippet is characteristic of Reinertsen's writing style and reasoning. He shows how the actions of people inside traditional systems are motivated by their rational assessment of their own economics. By setting up the wrong incentives, we are rewarding the very behaviors that we seek to prevent. Reinertsen has a visceral anger about all that waste, and his stories are crackling with disdain for the people who manage such systems - especially when their actions are motivated by intuition, voodoo, or blindness. Startups are frequently guilty as charged - the 4-year death march example above could be written about dozens of venture-backed companies slogging it out in the land of the living dead.

Reinertsen does not speak about startups specifically - his book is meant to speak broadly to product development teams across industries and sectors. Yet his analysis of the sources of waste in development and the remedies that allow us to iterate faster are especially useful for startups. There is an important caveat, however. Product development in established companies and markets has a clear economic rationale to judge effectiveness and productivity. The goal is to increase profitability by making high-ROI investments in new products. To give one example, Reinertsen emphasizes the power of measuring the cost of delay (COD) of a new product. That is, in order to make economically rational decisions about cycle time for a given process, we should understand what it costs the company if the products produced by that process are delayed by, say, one day. Armed with that information, we can make rational trade-offs. Take one of Reinertsen's example:

Unhappy with late deliveries, a project manager decides he can reduce variability by inserting a safety margin or buffer in his schedule. He reduces uncertainty in the schedule by committing to an 80 percent confidence schedule. But, what is the cost of this buffer? The project manager is actually trading cycle time for variability. We can only know if this is a good trade-off if we quantify both the value of the cycle time and the economic benefit of reduced variability.

Does this sound familiar? Many of the startups I talk to - and their boards - seem to equate ability to "hit the schedule" with competence and productivity. Yet timely delivery of new features often comes at the expense of agility, especially if cycle times are long. That is often a bad trade (although, as I'm sure Reinertsen would hasten to add, not always!). For example, many startups would do better by removing buffers from their schedules, embracing the variability of their delivery times, and reducing their cycle times.

Even worse, and unlike their established counterparts, startups often experience a non-quantifiable cost of delay. In a truly new market, we face no meaningful competition, there are no tradeshows to present at, and customers are not clamoring for our product. This means that there are no external factors that argue for shipping product on any given day. A day delay has almost no cost, as far as profitability is concerned. Remember that startups operate by a different unit of progress: what I call validated learning about customers. Any activity that promotes learning is progress, and productivity needs to be measured with respect to that. And that's also where we need to modify some of the specific practices Reinertsen recommends. If the product development team can be engaged in activities that promote business learning at the expense of shipping - or even selling - product, that's a good trade. Hence the need for partitioning our resources into a separate problem team and solution team. As with any methodology, applying the principles faithfully may require modifying the practices to fit a specific context.

Let me close with an excerpt of Reinertsen at his best, using an unexpected example to illustrate the power of fast feedback to make learning more efficient:

It should be obvious that fast feedback improves the speed of learning. What may be less obvious is that fast feedback also increases the efficiency with which we generate information and learn new things. It does this by compressing the time between cause and effect. When this time is short, there are fewer extraneous signals that can introduce noise into our experiment.

Team New Zealand designed the yacht that won the America's Cup. When they tested improvements in keel designs, they used two virtually identical boats. The unimproved boat would sail against the improved boat to determine the effect of a design change. By sailing one boat against the other, they were able to discriminate small changes in performance very quickly.

In contrast, the competing American design team used a single boat supplemented by computer models and NASA wind tunnels. The Americans could never do comparison runs under truly identical conditions because the runs were separated in time ...

Team New Zealand completed many more cycles of learning, and they generated more information in each cycle. This ultimately enabled them to triumph over a much better funded American team. It is worth noting that Team New Zealand explicitly invested in a second boat to create this superior test environment. It is common that we must invest in creating a superior development environment in order to extract the smaller signals that come with fast feedback.

There's far more material in this book that I would love to be able to excerpt. Unfortunately, each principle builds on the previous ones so tightly that it's hard to form coherent excerpts without quoting the whole thing. And that's exactly my point. When we're ready, this book has a tremendous amount to teach all of us. It's not a beginner's guide, and it doesn't hold your hand. Instead, it tackles the hard questions head-on. I've read it and re-read it; for a process junkie like me, I just can't put it down. I hope you'll enjoy it as much as I have.

The Principles of Product Development Flow: Second Generation Lean Product Development

I recently passed my ten-year anniversary of becoming an entrepreneur. I almost didn't realize it, but there's no escaping the math. In the summer of 1999, I started working on a startup from my college dorm. I'd eventually take a leave of absence from school and pursue it full-time, making just enough progress to catch the tail end of the dot-com bubble - and all of the dot-bomb crash. As we say, it was a "good learning experience."

Since then, entrepreneurship has occupied me in one form or another pretty much full-time. Much of what I've learned over the years has been invested in this blog, and that makes creating a sweeping summation challenging. I'm honored to be advancing the work of putting entrepreneurship on a more rigorous footing. But that's still in the future. Looking back, what strikes me the most is not how much I've learned - it's how much time I wasted on stuff that turned out to be utterly unimportant.

I pretty much missed all the trends. I'd been on the internet since I was playing MUDs as a kid, but by 1999 I felt I'd already missed the boat. All the good domain names were taken, all the good ideas were being implemented. If I'd bought just a handful of the "best of the rest" domain names that were available at the time (for a whopping $70 each), I probably could have just retired right then. And the great ideas that became today's successful tech startups dwarf anything that had been done to that point. I just couldn't imagine what the next ten years of innovation would look like. Yet my feeling of having missed out prevented me from experimenting with ideas that might have worked.

Nonetheless, my first startup was a tool for college students from elite colleges to create resumes and help them find jobs. Getting students to create their online profile was easy, but getting employers to pay for access proved difficult. Unfortunately, we were fixated on "building a real business" and never noticed that maybe students would want to share their profiles with each other. Could we have built the first college-based social network five years before Facebook? Maybe, but the thought never even entered our minds. (You can even see the humiliating evidence of my smug incompetence in this absurd article from 1999.) We were focused on revenue, but we didn't understand that revenue is not important for its own sake in an early stage company. Instead, we should have thought of it as an indication of validated learning.

And speaking of Facebook, I definitely didn't think it was a good idea when I first heard about it. Heck, I'd already seen Friendster flame out. What was different this time? And Google? No business model, either. I turned down two opportunities to interview at Google in its pre-AdWords days. It seemed like just a bunch of research-oriented PhD's. Oops. And then, at my first Silicon Valley startup, I watched friends get laid off in successive waves as it started to fail. Almost all of them got scooped up by pre-IPO Google this time. I was "lucky" to not be laid off, or so I thought. Yet, as it turns out, the earlier you got laid off, the earlier you got your Google options. That year, right before the IPO, those months mattered a great deal in terms of financial outcomes.

And while I'm confessing, let me add that I knew Matt Cohler way before he was famous. When he left his consulting job to join LinkedIn (whatever that was), I didn't think twice about it. In fact, I remember sending him and his obscure-to-me co-founder (aka Reid Hoffman) a bug report early-on, instead of taking them up on their offer of an in-person meeting. Doh! And when Matt left LinkedIn to take the reins at Facebook; once again, it didn't register. I was much more focused on other transient success stories of the day. I managed to be envious of dozens of other companies, founders, and colleagues who seemed to be having tremendous success but later turned out to be a mirage. If you'd asked me to rank the top most important people I'd met that year, I doubt it would look very impressive in retrospect.

I'm confident of that last statement, because I made the same mistake again a few years later, when I won an award in 2007. BusinessWeek named me one of the top young entrepreneurs in tech, based on my work at IMVU. Being called a techno-wonderboy in front of everyone I knew was pretty strange, and it felt stranger still to be taking credit for the hard work of the many people who really made IMVU a success. But they were very supportive, and the experience was a good one. Trying to take full advantage of the opportunity, I even reached out and met a few of the other award winners. But, looking back, was it obvious which of the other winners were destined to create world-changing companies? Nope. I completely missed Twitter, for example, which was just one more company to me. Oops.

And yet, missing out on these trends wasn't the end of the world. If I had joined Google early, I'd never have had the opportunity to be part of the founding of IMVU. Then I wouldn't have the chance to work with the incredible employees and mentors from whom I learned so much. And, as I've said many times on this blog, if it weren't for those colossal failures and embarrassing missteps, I'd never have learned anything of significance. So, looking back, I'm grateful for the failures and missed opportunities, embarrassing though they are.

One thing really stands out to me today. I wasted a lot of energy, time, and passion on trend-spotting and trying to compare my success with others. Is it really worthwhile spending time and money trying to impress each other with our supposed successes, especially in a business where real feedback can take five or ten years? We go to mixers, buy fancy offices, focus on PR, and try to one-up each other. I think it's wasteful. Instead, let's focus on building companies that matter, on creating real value for customers, and learning. In time, success will come. And if it doesn't, at least you'll have spent your time doing something intrinsically worthwhile.

In the meantime, don't worry if you can't spot the trends. Neither can the rest of us (well, except for Matt Cohler).

"Okey, watch Tahan ikut abang. Nama abang, Ahmad Mukrim. Panggil je Abang Mukrim."
Penampilannya agak menarik. Menyarungkan cekak rambut di kepala. Kelihatan mesra dan humor.

"Okay, kat sini kena ikut peraturan. Tak boleh ikut kepala sendiri. Sesiapa yang langgar peraturan akan dihantar balik serta merta. Barang-barang yang diharamkan adalah rokok, duit, kad pengenalan, telefon bimbit, semua jenis alat elektronik dan majalah-majalah. Kalau ada sila serahkan kepada saya. Di sini kita akan menjalani kehidupan 'back to basic'. Semua benda-benda itu tidak diperlukan di sini.





"Kalau takde rokok matilah saya bang. Bagila sehari sebatang ke. Saya sehari boleh habis sekotak bang. Jadi gila kalau saya tak hisap 7 hari." Rashid tiba-tiba memecah suasana. Budak seorang ni memang perokok tegar. Rokok untuknya sudah kemestian, seperti mestinya orang Melayu makan nasi hari-hari."

'Dahsyat mamat ni. Sekotak rokok tu mesti dah 6-7 ringgit. Sehari sekotak, banyak betul di bakar duit. Kalau sebulan istiqamah dia hisap, nak dekat RM200 lebih terbakar. Tentu baik kalau duit tu dibuat sedekah atau infaq di jalan dakwah. Ramai ikhwah-ikhwah yang pergi program dakwah yang memerlukannya. Syazwan tu kadang-kadang terpaksa ikat perut sebab nak simpan duit untuk follow up sekolah. Tentu senang hati Syaz kalau dapat bantuan tu. Semoga Allah memberikannya peluang untuk memperbaiki diri.' Ibrahim bermonolog sendirian.

"Jangan risau, abang simpan je. Tak amek sebatang pun. Sumpah. Alah, seminggu tak hisap takde matinye. Kalau mati nanti, abang pesan kat orang yang tanam tu untuk letak sekali rokok kesayangan awak tu dalam lubang kubur awak." Abang Mukrim berseloroh. Pelajar lain ketawa terkekeh-kekeh mendengarnya. Ibrahim turut tertawa. Rashid mencebikkan muka.

"Abang, boleh tak Fie nak call mak Fie dulu. Seminggu takde handphone ni, risau pulak dia nanti." Seorang pelajar perempuan bersuara. Sofia Afirah nama diberi. Lebih mesra dengan panggilan Fie. Kelihatan agak manja dalam berbicara.

"Hah, boleh-boleh..telefon mak korang, pesan jangan sedih-sedih. Seminggu je korang off hanphone. Korang pun takkan nak cerita semua kat parent korang kan? Ada orang tu nak pergi tandas cerita, nak makan cerita, semua nak cerita. Balik nanti korang ceritalah semuanya sekali."

'Ish, perempuan ni, kenapalah dia cakap dengan nada macam tu. Cakap nada biasa-biasa sudahla. Muka pun boleh tahan. Sure dah ada balak nih. Astaghfirullah! Apa yang aku fikir ni? Dahla pandang dia lama pulak tadi. Ya-Allah, peliharalah hatiku.' Hati kecil Ibrahim terdetik. Dia mengakui, kisah silamnya banyak mempengaruhi dirinya. Dia pernah bercinta dahulu kerana tertarik dengan seseorang yang mempunyai daya tarikan seperti Fie. Walaupun ia hanya tinggal sejarah, namun karat jahiliyyahnya masih berberbaki dan perlu terus dikikis.

"Okey, kalau semua dah serahkan barang-barang, kamu semua boleh pergi ke Dining Hall untuk lunch. Tinggalkan beg pakaian di sini. Lepas makan boleh balik ke dorm masing-masing. Lelaki di dorm Tahan dan perempuan di Dorm Irau.Tapi sebelum tu, pastikan korang buat checkup untuk H1N1. Jangan tak check, mana tahu ada di antara kamu ni pembawa virus! Nanti habis satu school ni kena kuarantin. Kita akan berkumpul semula di sini pukul 4.30 pm untuk Opening Ceremony. Ada apa-apa soalan?"

"Bang, dorm kami kat mana?" Ibrahim bersuara.

"Tu kat atas sana. Dorm Tahan yang paling tinggi tu," ujar Abang mukrim sambil menundingkan jarinya ke atas bukit yang terletak di timur laut dewan.

"Waah..tingginya!" Mereka sekumpulan hampir menjerit serentak. Tempat kediaman itu memang sangat tinggi. Mungkin 30 meter dari paras laut. Untuk sampai ke atas perlu menapak, satu-satunya cara yang ada. 7 hari yang bakal dihadapi tergambar amat melelahkan.



Ternganga mereka tidak lama. Perut yang lapar lebih merunsingkan. Mereka pun beramai-ramai bergerak menuju ke Dewan Makan ataupun Dining Hall. Satu watch akan duduk makan bersama. Dua meja panjang yang digabungkan. Mereka duduk di atas bangku panjang menanti makanan dihidangkan. Untuk hari pertama mereka semua diminta untuk melakukan 'Silence Moment', atau upacara berdoa. Bagi yang bukan beragama Islam, dipersilakan mengikut kepercayaan masing-masing.

Ibrahim mengambil tempat di sebelah Rashid.

'Cuba aku borak-borak sikit dengan dia ni. Mungkin boleh buat kawan. Mana tahu dia ni ada potensi untuk ditarbiyah.' Ibrahim menanam tekad.

"Assalamu'alaikum. Kau ni batch mana ye? Tak pernah tengok muka kau ni. Mesti kau batch Julai kan? Nama aku Ibrahim. Kau panggil je Im. Nama kau siapa?"

"Wa'alaikum salam. Haah, aku batch Julai la. Nama aku Rashid. Aku pun tak pernah tengok muka kau. Kau sekolah kat mana dulu?"

"Aku SMAP Labu, Negeri Sembilan. Kawan aku ada yang sama batch dengan kau. Kau mesti kenal Jamal kan? orang panggil dia Jemmol."

"Ha..kenal-kenal. Kitorang geng kut. Aku ni jiran kau la, SASER."

"La, ye ke..tak sangka. Patut muka macam budak Sains Seremban!"

"Ada la pulak muka budak SASER?"

"Ye la, dari rambut kau aku dah tau, memang kurang mandi. SASER kan selalu takde air. Haha..aku gurau je."

"Ceh kau. Kutuk sekolah aku ye. Tapi memang SASER selalu takde air. Kadang-kadang aku pergi tandas sekolah nak mandi. Tapi mandi tetap mandi. Kat SASER takde kambing."

"Haha..ko ni kelakar la. Em, ko nampak happy je? Tak risau dah pasal rokok kau tu?"

"Huisyh, mana tak risau beb. Tangan aku dah menggeletar ni. Ni lepas makan ni aku rasa nak hisap sebatang, tapi mamat tu dah ambik semua stok aku la pulak. Aku rasa nak deal sikit la dengan dia. Mana tau leh dapat sebatang dua. Dia nampak macam sempoi je."

"Sabarla Rashid. Seminggu je. Bukan setahun. Puasa kan leh tahan sebulan."

"Sebulan tu siang je. Malam leh hisap balik. Tak la tekanan sangat aku. Kau tau Im, aku dulu siap buka puasa hisap rokok tu. Kemaruk gile."

'Ni dah lebih dia nih. Bangga sangat dengan rokok dia.' Ibrahim sudah mula rimas.

"Best sangat ke hisap rokok ni? Bukan busuk ke? Lepas hisap batuk-batuk pulak. Duit pun habis."

"Kau tak tahu. Kena cuba dulu, baru tahu. Ko pernah hisap?"

"Aku belum lagi. Tapi kawan-kawan aku dulu ada ajak. Mula-mula macam nak gak. Tapi aku teringat 3 benda je, terus tak jadi."

"Hah, apa?"

"Satu, kalau aku hisap, nanti ketagih, susah nak tinggal. Habislah duit aku nak beli rokok. Beli, lepas tu bakar, macam bakar duit je kan? Membazir. Membazir tu kan kawan syaitan. Dua, nanti dah tua aku tak sanggup nak kena kanser paru-paru. Sayang aku dengan badan kecil aku ni. Baikla aku mati cara mulia sikit. Huhu.. Tiga, orang selalu kata, hisap rokok ni tak haram, makruh je. Walaupun ada pendapat yang kata haram. Tapi aku ambil jalan selamat je. Mana tahu nanti kat akhirat Allah kata haram, aku insya-Allah terlepas. Tapi depends pada orang la. Aku sampai bila-bila, takkan hisap kut."

Rashid memandang Ibrahim dengan mengerutkan kening. Terdiam.

'Direct sangat ke ayat aku tadi? Harap-haraplah dia tak ambil hati.'

Ibrahim berfikir sendirian. Tidak lama kemudian makanan terhidang. Sambil makan mereka terus berbual mesra. Rashid kelihatan tidak mengambil hati. Ibrahim cuba menukar topik perbualan ke mana-mana. Sesekali dia menegur teman-teman sekumpulan yang lain, bertanya nama dan asal usul. Dia cuba sedaya upaya menjadi seramah mungkin. Namun dalam hatinya masih risau akan penerimaan Rashid. Yalah, luka di tangan, nampak darahnya, luka di hati siapa yang tahu? Terbakar di kampung, nampak asapnya, terbakar di hati, siapa yang tahu?



bersambung...