Archives

What I learned on pre TestBash2017 Brighton meetup (zagorski software tester)

On March 30, 2017, in Syndicated, by Association for Software Testing
0

Reading Time: 2 minutesTL;DR Next series of post is about my takeaways from Brighton TestBash2017 conference. First was pre TestBash meetup. That meetup was day before workshop day. I came late, and everybody was already in the game mood. I noticed that a lot of games were played. I joined to table with following setup. One card was … Continue reading What I learned on pre TestBash2017 Brighton meetup

Do you see what I see? (Nicky Tests Software)

On March 30, 2017, in Syndicated, by Association for Software Testing
0

Yesterday I had an interview with the Test Manager for a potential project and the subject of providing valuable information, as testers, came up.We had a bit of back and forth regarding what exactly is valuable information – I asked him what the term …

מותו של הבודק הידני Abolishing manual testers (אשרי אדם מפחד תמיד Happy is the man who always fears)

On March 28, 2017, in Syndicated, by Association for Software Testing
0
 https://s-media-cache-ak0.pinimg.com/736x/94/6c/c7/946cc7383075dc6f3e645a5e27b0d794.jpg

במפגש הבדיקות האחרון העליתי נושא קטן שמציק לי כבר לא מעט זמן – הגיע הזמן להפסיק עם כל הקשקוש הזה של “בודק ידני”. זמנו של הדינוזאור הזה להיכחד חלף ועבר לו מזמן. לא, אני לא מנסה לומר שכל בודקי התוכנה צריכים ללמוד לתכנת (אני חושב שתכנות הוא כלי חשוב לבודקי תוכנה שכדאי מאוד שיהיה בארגז הכלים שלכם, אבל זה לא הנושא כרגע), אני גם לא רוצה לדבר על האפשרות המסקרנת לפיה תפקיד בודקי התוכנה ייעלם וייטמע בתוך צוותי הפיתוח, הבעיה שלי היא עם המונח “בודק ידני”.

כמובן, אני לא ממציא פה את הגלגל ולא הראשון שכותב על זה משהו, אבל בכל זאת יש משהו קטן שאני רוצה להוסיף – “בודק ידני” זו הגדרת תפקיד שצריכה להימחק מהלקסיקון של כולם, ובראש ובראשונה – של בודקי תוכנה.
פריט המידע היחיד שההגדרה הזו תורמת הוא “אני לא כותב קוד”. יש המון כישורים שבודקי תוכנה מפעילים כל הזמן – ניתוח מערכות ויצירת מודלים, הערכת סיכונים, שימוש בSQL, בדיקות ביצועים, אבטחה, חוויית משתמש, נגישות. בודקי תוכנה משתמשים במגוון כלים שדורשים מיומנות – וזה לא משנה אם מדובר בצב”ד ייעודי לחומרה ספציפי או בכלי הפיתוח המובנים בכל דפדפן. יש לא מעט תחומים בהם יכול בודק תוכנה להתמחות – “מומחה לבדיקות לוקליזציה” לא נשמע כמו משהו מופרך, נכון? גם לא מומחה לבדיקות UX. על מומחי בדיקות אבטחה או ביצועים כולנו שמענו. אבל “מומחה לבדיקות ידניות” ? מה זה בכלל אומר?
“בודק ידני”, כפי שהוא מתורגם היום בשוק, הוא מונח שמשמש כדי לתאר מה בודק תוכנה לא עושה, הגדרת התפקיד הזו היא גם מעליבה (האם הייתם קוראים לשף שמתמחה במטבח האיטלקי “השף שלא מכין סושי”?) וגם מגבילה ומצמצמת  – כי בתפקיד מוגדר מה לא עושים. קמת בבוקר עם רצון ללמוד לכתוב קוד וליישם את זה בעבודה כי זה הדבר ההגיוני לעשות במשימה כלשהי? תגובת הסביבה תהיה פחות או יותר “אתה רוצה להחליף תפקיד לכתיבת אוטומציה?” לעומת זאת, אילו הגדרת התפקיד הייתה “בודק חוקר” (או כל הגדרה חיובית אחרת כמו “בודק פונקציונלי” או סתם “בודק תוכנה”), אפשר היה להוסיף בשקט כישורי תכנות לתוך סל הכישורים שאנחנו מציעים. לא לחסום את עצמנו בתירוץ של “אני בודק ידני, כתיבת קוד היא מחוץ להגדרת התפקיד” ולא לתת לאחרים פתח לנסות לחסום אותנו באותו תירוץ.
אם על הדרך הצלחנו גם להפנות את הזרקור לכך שיש כישורים טכניים בבדיקות תוכנה שאינם קשורים לכתיבת קוד? מצויין. אולי נצליח למחוק גם את המונח המטעה “בודק עם כישורים טכניים”.

——————————————————————————————–

At the last testing meetup I raised a subject that bugs me for some time now – it’s time to stop using this nonsensical term “manual tester”. It’s a dinosaur that should have long been extinct. No, I’m not trying to say that all testers should learn programming (I think programming is a very useful skill to have for a tester and would recommend any tester to have it in their toolbox, but this is not the subject here), nor do I want to discuss the question “will testing be assimilated into the developers’ role?”. My issue is with this specific term. 
Of course, I’m not the first to write something on the subject and probably not the last, but there’s something I want to add: “Manual tester” is a term that should be eradicated from everyone’s vocabulary, and software testers should be the first to do so. 
The only piece of information one gets from this term is “I don’t write code”. There are a lot of skills that testers use all the time – Analysing systems and creating models, assessing risks, using SQL, testing security, performance, UX & accessibility. Testers also use tools that require skill & learning, and it doesn’t matter if it’s a test tool tailored for a specific hardware or if it’s the browser’s developer tools. In addition, there are a lot of areas in which a software tester can specialize: A UX testing expert isn’t far fetched, right? Neither is localization testing specialist, and we’ve all met some security and performance testing experts. But what would it mean to be a “manual testing expert”? does this even say anything? 
“Manual tester”, the way it is used in today’s market, is a term used to describe what a tester does not do. It is both derogatory (would you call a chef who specializes in the Italian cuisine “the chef that does not make sushi”? ) and confining. It is confining since the job description states quite clearly what one is not expected to do. If a person wakes up one morning and decides to learn some coding and apply it in work since it’s the reasonable thing to do in a given situation, the reaction of the environment would range between “I thought you are a manual tester” to “are you trying to switch\advance your career path to automation?” If, however, we would have used a more constructive term (such as exploratory tester, functional tester or even simply tester), writing code would not be something marked as out-of-scope but rather what it actually is – one way we can choose to get things done. 
And, if in the process we’ll manage to turn the spotlight to the fact that there are some technical skills in testing that are not related to coding skills, it can be nice too. Who knows, maybe we’ll manage to remove the almost-as-bad term “technical tester” as well. 

Reading & Writing, the I/O (Chris Kenst's Blog)

On March 27, 2017, in Syndicated, by Association for Software Testing
0

I grew up with a lot of books in our home but I rarely recall someone reading them. My mother was perhaps the most avid reader with her interest in romance novels while my dad read the daily newspaper and his magazines. Their library was (and still is) a homage to the books they read, […]

Rodent Controls (Hiccupps)

On March 26, 2017, in Syndicated, by Association for Software Testing
0

So I wasn’t intending to blog again about The Design of Everyday Things by Don Norman but last night I was reading the final few pages and got to a section titled Easy Looking is Not Necessarily Easy to Use. From that:How many controls does a devi…

The Bad of Event Sourcing – The Pains of Wrongly Designed Aggregates (The Continuous Improver)

On March 23, 2017, in Syndicated, by Association for Software Testing
0

Event Sourcing is a brilliant solution for high-performance or complex business systems, but you need to be aware that this also introduces challenges most people don’t tell you about. In June, I already blogged about the things I would do differently next time. But after attending another introduction to Event Sourcing recently, I realized it is time to talk about some real experiences. So in this multi-part post, I will share the good, the bad and the ugliness to prepare you for the road ahead. After having dedicated the two last posts on the good of event sourcing, let’s talk about some some of the pains we went through.

Designing your domain based on ownership

When I started practicing domain driven design almost 9 years ago, I thought I knew all about aggregates, value objects, repositories, domain services and bounded contexts. I read Eric Evans’ blue book, Jimmy Nilsson’s white book and various papers such as InfoQ’s DDD Quickly. Our main driver for designing our aggregates was based on who owns what property or relationship. We designed for optimistic concurrency, which meant that we needed to use the version of the aggregate to detect concurrent updates. The same applied to relationships (or association properties on a technical level). If it was important to protect the number of children a parent has, you needed to add the child through the parent. Since we were using an OR/M, we could use its built-in versioning mechanism to detect such violations. Surely I had not heard of eventual consistency or consistency boundaries yet, and Vaughn Vernon had not published his brilliant three-parts series yet. In short, I was approaching DDD as a bunch of technical design patterns rather than the business development experience it is supposed to be.

Relying on eventual consistent projections

Because we didn’t consider the business rules (or invariants) enough while designing our aggregates, we often needed to use projections to verify certain functional scenarios. We knew that those projections were not transactional consistent with the transactions, and that other web requests could affect those projections while we were using it. But the functional requirements allowed us to work around this for the most part. Until the point that we wanted to make a projection run asynchronously of course. That’s the point were we either had to stick to an (expensive) synchronous projector, or accept the fact that we couldn’t entirely protect a business rule. Next time, I’ll make sure to consider the consistency of a business rule. In other words, if the system must protect a rule at all costs, design the aggregates for it. If not, assume the rule is not consistent and provide functional compensation for it.

Bad choice in aggregate keys

As many information management systems do, we had an aggregate to represent users. Each user was uniquely identified by his or her username and all was fine and dandy. All the other aggregates would refer to those users by their username. Then, at a later point of time, we introduced support for importing users from Active Directory. That sounded pretty trivial, until we discovered that Active Directory allows you to change somebody’s username. So we based our aggregate key on something that can change (and may not even be unique), including the domain events that such an aggregate emits. And since a big part of the system is using users to determine authorization policies, this affected the system in many painful ways. We managed to apply some magic to convert the usernames to a deterministic Guid (ping me for the algorithm), but it still was a lot of work. Next time, I will just need to accept that no functional key is stable enough to be the aggregate key and start from a Guid instead.

Using domain events as a way to externalize business rules

The system that I worked on is highly customizable and has a domain with many extension points to influence the functional behavior. At that time, before we converted the system to Event Sourcing, we used Udi Dahan’s domain event implementation to have the domain raise events from inside the aggregates. We could then introduce domain event handlers that hook into these and which provide the customized behavior without altering the core domain. This worked pretty well for a while, in particular because those events were essentially well-defined contracts. With some specialized plumbing we made sure all that code would run under the same unit of work and therefor behaved transactionally.

But when we switched to event sourcing, this mechanism became a whole lot less useful. We had to make decisions on many aspects. Are the events the aggregates emit the same as domain events? Should we still raise them from inside the aggregate? Or wait until the aggregate changes have been persisted to the event store? It took a while until we completely embraced the notion that an event is something that has already happened and should never be used to protect other invariants. Those cases that did misuse them have been converted into domain services or by redesigning the aggregate boundaries. You can still use the events as a way to communicate from one aggregate to another, but then you either need to keep the changes into the same database transaction, or use sagas or process managers to handle compensation or retries.

Domain-specific value types in events

Remember the story about how we choose the wrong functional key for a user and had to touch a large part of the code base to fix that? As with any bad situation, people will try to come up with measures that will prevent this in the first place. Consequently, we decided to not directly use primitive types in our code-base anymore, and introduce domain-specific types for almost everything. For instance, a user was now identified by a UserId object with value semantics. So whether it contained a Guid or a simple string was no longer of concern for anything but that type itself.

But as often happens with a lot of new ‘practices’, we applied it way too dogmatic. We used them everywhere; in commands, aggregates, projections and even events. Naïve as we were, we didn’t realize that this would cause a tremendous amount of coupling between the entire code-base. And I didn’t even mention the horror of somebody changing the internal constraints of a value type causing crashes caused by an old event that couldn’t be deserialized because its old value didn’t meet the new constraints. Having learned our lessons, nowadays we make sure we consider the boundaries of such value types. You may still use them in the aggregates, domain services and value objects within the same bounded contexts, but never in commands, projections and events.

Event Granularity

Consider a permit-to-work process in which the risk assessment level can be determined to be 1 or 2. If the level is 2, the process requires a risk assessment team to be formed that will identify the real-world risks involved in the work. However, if the risk level is reduced to 1, then the team can be disbanded. To model the intent of this event, we have two options. Either we capture this situation by first emitting a couple of fine-grained MemberRemovedFromRiskAssessmentTeam domain events, followed by a RiskAssessmentLevelChanged domain event. Or we decide to capture this as a single RiskAssessmentLevelDemoted event. So which is better?

Considering the fact that we’re practicing Domain-Driven Design, I guess most people will go for the coarse-grained RiskAssessmentLevelDemoted event. And indeed, it does properly capture the actual thing that happened. But it has a drawback as well. Both the domain as well as the projection logic must know to interpret that event as a demotion in the actual level and the disbandment of the risk assessment team. But what happens if the expected behavior changes in a later version of the software? Maybe the rules change in such a way that team will need to be kept intact, even if the level changes. If you take the coarse-grained event path, you will need to duplicate that logic. We don’t share code between the command and query sides in a CQRS architecture style. And what happens when you rebuild domain aggregates form the event store that existed before the software update was completed? There’s no ultimate answer here, but considering the relatively high rate of change and configurability in our system’s business rules, we choose for fine-grained events.

Event Versioning

Much has been written about event versioning and there are plenty of examples how to convert one or more older events into a couple of new events. We use NEventStore, which provides a simple event upconversion hook out of the box. That library uses Newtonsoft’s Json.NET to serialize the events into its underlying storage, which, by default, includes the .NET runtime type of the event in the JSON payload. This has caused us some pain. What if the .NET namespace of the event type changes because somebody refactored some of the code? Or what if the event is moved from one DLL to another because we decide two split one project in two or two projects in one? We had to tweak the JSON serializer considerably to ensure it would ignore most of the run-time type info and find a reasonably stable mechanism to match a JSON-serialized event with its run-time .NET type. Maybe there’s an event store implementation that solves this for you, but we have not come across one yet.

Bugs

Great developers don’t write bugs I often hear some of my colleagues say, but somehow I keep running into apparent less-than-great-developers. So bugs are inevitable. We didn’t have too many problems with bugs affecting the domain. Either we could handle them by changing the way the existing events were used to rebuild the domain, or by repairing flawed events using smart upconverters. However, I do remember a particular painful bug that was really hard to fix. One of our background processes was responsible for importing information about a back office system into the domain. It would collect the changes from that system and translate them into a couple of commands that were handled by the domain. All was well for a while, until we got some reports about some weird timeouts in the system. After some investigation we discovered that a particular single aggregate had more than a million events associated with it. Considering the average of a handful of events per aggregate instance, this was a serious problem. Apparently the aggregate root contained a bug that caused it to be not so idempotent as it should be, injecting new events for things that didn’t even change. We finally managed to fix this by marking the stream as archivable, a concept we build ourselves. But it most definitely wasn’t fun….

What about you?

So what do you think? Do you recognize the challenges of designing your aggregates correctly? If not, what is your primary source for guidance on this complicated topic? I’d love to know what you think about this by commenting below. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for better aggregates.

Can You Afford Me? (Hiccupps)

On March 22, 2017, in Syndicated, by Association for Software Testing
0

I’m reading The Design of Everyday Things by Donald Norman on the recommendation of the Dev manager, and borrowed from our UX specialist. (I have great team mates.)There’s much to like in this book, includinga taxonomy of error types: at the top level …

מפגש בודקים – סיכום testing meetup (אשרי אדם מפחד תמיד Happy is the man who always fears)

On March 22, 2017, in Syndicated, by Association for Software Testing
0
התחלה טובה למפגש

ביום חמישי האחרון התקיים בתל אביב מפגש בודקי תוכנה, ואחרי שלא היה מפגש JeST מזה זמן מה, זה נחמד לראות עוד סדרות מפגשים קמות. זה הזמן להודות לניצן ואיגור שדחפו וארגנו את המפגש הזה, לאביבית שהזמינה את המפגש להתארח בחברת clicktale, ולאנה שהעבירה את ההרצאה שפתחה את הערב. 

הערב התחיל בהרצאה בנושא מעניין מאוד – ניהול סיכונים. אנה הציגה את בנושא באופן יסודי למדי, וניהלנו דיון על מהו סיכון, מי מקבל את ההחלטה אם לשחרר גרסה לאוויר או לא, איך נכון להתייחס לסיכון ואיך לדווח על ממצאים ועל סיכונים. בסך הכל – מבוא מצויין לנושא. עם זאת, נקודה אחת שאולי כדאי לשים אליה לב היא העובדה שההרצאה הייתה תיאורטית מאוד והתבססה על מציאות שרוב הנוכחים לא רואים בחיי היומיום שלהם (באופן ספציפי – מחזור פיתוח ארוך ומלא מסמכים), מה שהפך את היישום של מה ששמענו למורכב יותר ואת ההרצאה למועילה יותר דווקא לאלו שהנושא לא היה חדש להם והיו מסוגלים לעשות לבד את הצעד הנוסף שנדרש כדי לשייך את הרעיונות ששמענו לסביבת העבודה הדינמית יותר בה הם חיים, בעוד האחרים קצת התנתקו לקראת הסוף. למרות זאת – תוך כדי ההרצאה ואחריה התפתחו כמה דיונים קצרים וממוקדים סביב הנושא הכללי של ניתוח סיכונים והחוויה הכללית הייתה מעניינת מאוד.
לאחר מכן במהלך ההפסקה אנשים עשו את הדבר הנכון והתפצלו לקבוצות שיח קטנות. ובכן, זה בדיוק מה שעשיתי גם אני – מצאתי מישהי שהמתינה לסוף ההפסקה בפינה ואמרתי שלום, מן הון להון – מתישהו נגמרה ההפסקה והפריעה לנו באמצע שיחה מעניינת.
לאחר ששככו הדי השיחות מההפסקה, ניצן פתח את הדיון הכללי בהצגת שאלה חשובה – איך אפשר להפוך מבודק טוב לבודק מצויין. באופן אישי, אני אסתפק בלהפוך לבודק טוב, אבל זה תמיד טוב לכוון גבוה. בשלב הזה, כמובן, כבר היה ברור בדיוק מי בחדר מדבר יותר ומי נחבא אל הכלים. כדי לתקן את זה, לפחות קצת, ניצלתי פטנט שנתקלתי בו במהלך מפגשי קפה-נטול (lean coffee):  בעוד ניצן מדבר, עברתי בין האנשים וחילקתי לכל אחד כמה פתקים וחיכיתי להפסקה קטנה שתאפשר לי להסביר לכולם את החוקים – כל אחד כותב לפחות שני רעיונות (יכול להיות שאלו מכם שעובדים בסוג של סקראם מכירים את השטיק הזה מישיבות רטרוספקטיבה – זה עובד שם באותה מידת הצלחה). למה שניים ולא אחד? כי רציתי להכריח אנשים לעבור את מחסום הבושה ולא להסתפק בפתק בודד, וכי כשמנסים למצוא שני רעיונות שונים מספיק זה מזה, הרעיון השלישי והרביעי מגיעים גם בלי הזמנה. אחר כך ניצלתי את מעמד המנחה שניכסתי לעצמי (ועם המארגנים הסליחה) כדי להקים אנשים ולשים את הפתקים על הלוח, לקבץ אותם לקבוצות ואז בחרנו כמה פתקים ודיברנו קצת על כל אחד מהם. את רשימת הנושאים המלאה אפשר למצוא (ותודה לקובי שאסף את הנושאים) כאן.
כשירדנו למטה, רוח הכנסים דאגה לנו, ובמקום שנצטרך למצוא פאב באזור (ויש כמה וכמה, כך זה נראה), חילקו למטה בירה וניגנו מוזיקה רועשת. נו, למה לא? בסוף נשארנו חמישה ודיברנו קצת בחוץ עוד כשעתיים – היה מוצלח למדי.

המפגש הזה היה הזדמנות להפגיש אנשים עם מגוון רחב מאוד של חוויות, כישורים וניסיון (מכאלו שמחפשים את העבודה הראשונה שלהם בתחום ועד כאלו שנמצאים במקצוע למעלה מעשרים שנה), ולמרות שכרגע מדובר בעיקר בניחוש שלי, אני חושב שרוב מי שהגיע למפגש הזה ירצה להגיע גם למפגש הבא.
אני עצמי, כמובן, מחכה בכליון עיניים למפגש הבא – השילוב של הרצאה ודיון פתוח קסם לי במיוחד, והגיוון המרשים של אנשים תרם רבות לדיונים מעניינים – תוך כדי ההרצאה, אחריה וגם בסוף המפגש.

———————————————————————————–

Last Thursday there was a testing meetup in Tel Aviv, the first one in a series of meetups that are dedicated to testing – not automation only (though it does not exclude automation), not a specific technology, simply testing. After quite a while without a JeST (Jerusalem software testing), it was nice to see a new meetup coming to life. I want to thank Nitzan and Igor for organizing this series, Avivit who invited us to ClickTale office and was a great hostess and Anna who presented the first talk in the meetup. 
The evening started with a very interesting topic – risk based testing. Anna gave a thorough overview of the subject, touching on why it is important to incorporate risk into our testing, and we had some great discussions about who decides to ship, how to treat risk and how to report on risks identified during testing. All in all – it was a very good intro to the subject. One point to keep in mind for the future, though, is that the talk was very theoretical and was deeply rooted in a reality that was foreign to most attendees  – a reality in which there is a place for quite heavy documentation and the release cycle is quite long. This made the talk more valuable to the more experienced people in the room who were already familiar with the concept of risk and could extrapolate from what was said to their day-to-day work.And indeed, some of the attendees seemed to doze off a bit. Despite that we had some interesting discussions during the talk and I found the entire experience interesting. 
After the talk, during the break, people did the right thing and split up to small groups for some chatting, which is exactly what I did: I spotted someone who was sitting alone in a corner and went to introduce myself and start a conversation. suddenly, the break was over and we had to cut our conversation short. 
Once the turmoil from the break broke off, Nitzan presented a question to the audience: What is required in order to transform from a good tester to a great one? Personally, I would be satisfied to simply be a good tester, but I can see the value of aiming high. At this moment, of course, it was already clear (from the mini-discussions we had) who were more likely to join the conversation and who would probably be silent for the entire meeting. To mitigate this, at least a little, I used something I encountered during lean coffee sessions (and some scrum retrospective) and distributed some post-it notes to each participant and asked each person to write down at least two ideas (why two? Because asking for one would have probably ended in each person writing down one note, with the shy ones skipping it altogether, and because trying to think of two distinct ideas is where other ideas come from). I then used the moderator position I appropriated to get people up and stick their post-its to the whiteboard, just to see how many ideas we had (If you can read Hebrew, you can find the subjects here thanks to Kobi who collected them), and then to facilitate the discussion around some topics and make sure that the silent ones at least got to choose a topic.

By the end of the meetup, the convention spirit took care of us, and we found out that down at the building entrance there was some music and free beer (something related to the fact that it was the night before St. Patrick’s day, I think) and so some of us stayed and talked a bit more for a couple of hours. Funny as it may be, it doesn’t matter how good was an event, it’s the unofficial parts which are the most memorable and enjoyable.

This meetup was a chance to get a wide variety of people together (how wide? if we limit ourselves to experience years only, we had people with over 20 years of experience together with some who are looking for their first testing job), and although it’s only my estimate, I think that everyone who were at this meetup will want to be in the next one as well.
Personally, I can’t wait to the next meetup to happen – I really liked the combination of a talk and an open discussion, and the vast array of different experiences contributed a lot to the interesting discussions – during the talk and after it. 

It is TestBash Brighton time! (zagorski software tester)

On March 18, 2017, in Syndicated, by Association for Software Testing
0

Reading Time: 3 minutesTL;DR This is my personal cheat sheet for TestBash Brighton 2017 testing gathering. Based on my previous conference experiences, I realized that I need a one stop shop reminder for conference activities. I will print out this blog post. Here it goes. Wednesday Pre-TestBash Meetup, 29-30 Surrey street, Brighton, BN1 3PA Starts at 7.00PM but it … Continue reading It is TestBash Brighton time!

A Field of My Stone (Hiccupps)

On March 18, 2017, in Syndicated, by Association for Software Testing
0

The Fieldstone Method is Jerry Weinberg’s way of gathering material to write about, using that material effectively, and using the time spent working the material efficiently. Although I’ve read much of Weinberg’s work I’d never got round to Weinberg on Writing until last month, and after several prompts from one of my colleagues.

In the book, Weinberg describes his process in terms of an extended analogy between writing and building dry stone walls which – to do it no justice at all – goes something like this:

  • Do not wait until you start writing to start thinking about writing.
  • Gather your stones (interesting thoughts, suggestions, stories, pictures, quotes, connections, ideas) as you come across them. 
  • Always have multiple projects on the go at once. 
  • Maintain a pile of stones (a list of your gathered ideas) that you think will suit each project.
  • As you gather a stone, drop it onto the most suitable pile.
  • Also maintain a pile for stones you find attractive but have no project for at the moment.
  • When you come to write on a project, cast your eyes over the stones you have selected for it.
  • Be inspired by the stones, by their variety and their similarities.
  • Handle the stones, play with them, organise them, reorganise them.
  • Really feel the stones.
  • Use stones (and in a second metaphor they are also periods of time) opportunistically.
  • When you get stuck on one part of a project move to another part.
  • When you get stuck on one project move to another project.

The approach felt extremely familiar to me. Here’s the start of an email I sent just over a year ago, spawned out of a Twitter conversation about organising work:

I like to have text files around [for each topic] so that as soon as I have a thought I can drop it into the file and get it out of my head. When I have time to work on whatever the thing is, I have the collected material in one place. Often I find that getting material together is a hard part of writing, so having a bunch of stuff that I can play with, re-order etc helps to spur the writing process.

For my blogging I have a ton of open text files:

You can see this one, Fieldstoning_notes.txt and, to the right of it, another called notes.txt which is collected thoughts about how I take notes (duh!) that came out of a recent workshop on note-taking (DUH!) at our local meetup.

I’ve got enough in that file now to write about it next, but first here’s a few of the stones I took from Weinberg on Writing itself:

Never attempt to write what you don’t care about.

Real professional writers seldom write one thing at a time.

The broader the audience, the more difficult the writer’s job.

Most often [people] stop writing because they do not understand the essential randomness involved in the creative process.

… it’s not the number of ideas that blocks you, it’s your reaction to the number of ideas.

Fieldstoning is about always doing something that’s advancing your writing projects.

The key to effective writing is the human emotional response to the stone.

If I’ve been looking for snug fits while gathering, I have much less mortaring to do when I’m finishing

Don’t get it right; get it written.

“Sloppy work” is not the opposite of “perfection.” Sloppy work is the opposite of the best you can do at the time.

Page 1 of 3123

Looking for something?

Use the form below to search the site:


Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!