|
 |
RSS Feed  |
a playground of art, photos, videos, writing, music, life |
|
|
You are here
|
Creativity!
|
Get it!
|
I like it!
|
Fun stuff!
|
About me...
|
| |
|
|
|
|
Random Quote
Literature is the immortality of speech.
-- August Wilhelm von Schlegel
|
|
|
|
|
|
Page Through Blog: << More Recent Posts | Home Page | Earlier Posts >>
Blog Archive by Month | Blog Archive by Story or Tag | Search Blog and Comments
For two days, I've been running through the scenarios for invitation-only events, and it's proven a lot more work than I expected, especially since everything for private events was so simple. But the workflow is quite different, and some of the scenarios raise some questions about how the rest is handled. All I know is that I want to put this piece of it to bed tonight before I go to bed. It's getting in the way of my development timeline, dammit. |
|
|
As I'm writing more functionality this morning in the events calendar, my own software caught me by surprise. 247Toolset has the ability to create private events that don't show up on the public calendar. When a person is logged into the system, they see the private events to which they have access. I always thought of this as internal admin meetings among the group. But frankly, if I create a private event and issue no one access to the event but me, each person in the organization could use this as a personal events calendar. Would they want to? I had a conversation yesterday with someone who owns 247Toolset and they're looking at ACT as a contact management system in-house. She asked the question, "Could I just use 247Toolset for that?" Her reasoning, which has been a principle goal of the platform all along, is that it brings all of their information into one place. There are a lot of cool tools out there, but never discount the beauty of simplified integration as a point of attraction. Here's the thing: because 247Toolset actually allows those in my network to manage their own information for me, which makes it more accurate and less time-consuming, and because it's coming awfully close to a full-fledged contact management system, I think I have some interesting angles I can play here with just a bit more thoughtfulness as I code. What's really blowing my mind: 247Toolset allows organizations to network their calendars together. That blend of personal calendars with organization calendars with niche community calendars... holy crap! ETC: Here are some screenshots, if you'd like to see them. Just click.     |
|
|
Wouldn't it be great to be able to toggle between the calendar view and a list of the events through the month? You betcha :)  I'm probably coding faster than I ever have, and this is likely my most productive week ever. That's kind of a crazy thing to say... |
|
|
One of the best ways for an organization to gain members and promote its mission into the community is to attend the events of others. It's impossible for an administrator to keep abreast of all of the events in the community that would prove beneficial to attend. But across all of its members, collectively, they might know all of them. So this morning, I'm creating the ability for members to suggest an event to the administrators through the events calendar. |
|
|
Today, I sat with an organization that purchased my platform and walked them through the features and options. I used to be able to do a pretty thorough demo in 10 minutes. I'm not sure I could do it in an hour now. I said last year that my primary purpose in life is driving value. Driving value is an additive force in the economy. It creates purpose and use from nothing and makes it attractive to purchase, which increases the velocity of money around those driving value. A few years back, the daughter of a friend of mine went to China, and being an excellent photographer, she took pictures of the communities she visited. Being an artist, she didn't focus on the "sights," per se... she instead took pictures of the small details of a well-crafted fence, or the ornate carving in a door, or the exquisite curve of a piece of glass blown into perfect shape. Over centuries, the community was improved by everyone, so that even the smallest of touches had great meaning.I hope that can be said of my life - that I added great and beautiful value. |
|
|
In addition to writing a ton of code, I'm writing the user manual, and I would argue that every developer needs to write their own manual. Not because it's for the user to read, but rather because it's for the developer to be forced into eating his own dog food, step by step. There is no better debugger than documenting your own path for others as they would use it. That process has been helpful to me to figure out the best way to help a person manage their activity as a non-administrator in 247Toolset.  Beyond creating their initial profile, a person has three reasons to return to the portal: - Record their response to a request for engagement
- Manage their current assignments
Manage their RSVP's to events
I've spent three hours so far this morning walking through this experience for the user again and again, clarifying my words and cleaning up the interface to give them what feels simple. When on an assignment, the administrator can issue tasks for the person assigned, and the person can record their status on the task. They can also record their time on an assignment.  This is not only applicable for the recruiters who use 247Toolset, but for non-profits as well, who have told me that they need an easy way to log a volunteer's hours - because sometimes the "volunteer" is compelled to be there because of a community service requirement. Walking through it, I thought of the enhancements I'm sure I'll be asked to make down the road. That clarity in what exists and that vision for down the road wouldn't have come were it not for the exercise of writing it out. |
|
|
Out: No-Fly Zone. In: Hypocrisy Zone. |
I'm not going to post any links for this or even elaborate - it's just obvious on its face. |
|
|
Back in late January, I wrote this post, explaining that the secret to great writing is rewriting - as I learned in college. It's become obvious over the past 3 weeks that I need to completely rewrite the permissions and approvals engine for 247Toolset. When you first approach a problem to solve, you come at it with your best information and your best solution. As you think it through, you learn more, and you make your first implementation. But the strength of any system is its flexibility to adapt to new needs. As new information comes to light, and as the initial unknowns are flushed out, the model implemented will either allow for enhancement or limit the business. At the point of limitation comes a decision: does the cost of limitation outweigh the cost of rewriting? If the answer is no, then you handicap your business through the known limitation and create workarounds, where necessary. If the answer is yes, then you embark on a rewrite and re-approach the problem with the new information you have. I first wrote the permissions and approvals engine four years ago. Now that I have a few dozen clients using 247, and now that I'm smarter for having listened to and watched the way in which they use it, it's time to rewrite. I've been involved in many organizations that encountered the rewrite vs. workarounds fork in the road. What I found is that companies almost never trust their own people to start from scratch and build it from the ground up. That's just dumb. I mean, it's one thing if you simply don't have the talent in shop to do it, as most small businesses do not. But for larger companies, they likely do have that talent in house. For whatever reason, they just don't trust that talent. So they end up buying into a system that meets most of what they need, and expend no small amount of effort squeezing that foot into the limitations of that new shoe. The problem with that approach is that it is still a system that limits the organization. Every time. They convert the fork in the road to become workarounds in current limiting system vs. workarounds in new limiting system. Writing and owning the entire system is not an option, and limitation becomes a way of life. Peter Drucker said: "Management is doing things right; leadership is doing the right things." Ever since I heard that, I knew that the optimum is: Do the right things right. Why choose between doing things right and doing the right things?In my experience, it is always better and more sustainable to solve the right problem in the right way at the earliest opportunity. In my experience, the only time that something is too costly to implement is when it is impossible, otherwise it's doable and the only challenge is choosing when and how. The only way you know the right problems to solve is by being as close as possible to the market. The only way to solve those problems in the right way is to implement as close as possible to the market. See the pattern? The problem with most of today's management is that they don't make a concerted effort to put themselves and their people close to the market. Therefore, ineffectiveness and inefficiency ensue, which paves the way for disruptive innovators and fearless competitors - which always costs the existing players far more for the avoidance and can threaten their very existence. That too is dumb. |
|
|
I've been wrestling with a need that's been expressed to me for some time, and today's development has led me to what I think is the answer. I won't say explicitly what the need is, but here's what seems like the answer: A person should be able to create their own reality without the hindrance of others checking their homework. Because Facebook, Twitter, LinkedIn, and so on have taught us one thing - which is at odds with reality - few people will publicly correct our homework.Said another way, being part of a network shouldn't require that everyone agree with everyone's version of what's really going on. Everyone should be allowed their own version. Today, after looking at 247Toolset, two people at the demo echoed comments that I've heard before - 247Toolset is like an organization having its own personal LinkedIn, but with functionality more targeted to an organization's needs.It's got me thinking... |
|
|
Don't Know What You Don't Know |
Back in 1995, I attended a software conference in Manhattan and Jim McCarthy was the keynote speaker. In a sea of suits, he showed up in a Hawaiian shirt and jeans with holes in them. He gave the best talk I've ever heard around software development. His first topic has always stayed with me, which was "Don't Know What You Don't Know." It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn't early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this "lucid ignorance," disaster will surely befall you.Human nature is such that we dislike not knowing things that are important to our well being. Since there is so much we don't know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their ignorance. You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. It requires mental and psychological strength to resist the normal human cravings for certainty and order. It especially difficult to believe in uncertainty when things have a veneer of orderliness, which is often the case. Pseudo-order is a maladapted defense against uncertainty. The organization surrounding you will undoubtedly abhor uncertainty, would infinitely prefer pseudo-order and will make countless attempts to magically convert your ignorance to knowledge. Your job is to make uncertainty an unshakable fact, and to coerce the reshaping of the surrounding organization to cope with the uncertain situation. The organization must learn to thrive in an uncertain environment for its own well being. You should expend a great deal of effort making sure that all the people on the project are aware of their ignorance rather than naively converting it to falsehoods. Bear down on them until they realize they haven't comprehensively assessed the unknowns. In the successful project, this is much easier in the early stages, or during times of change. This is no time for niceties. People ultimately prefer success even if disillusionment is a prerequisite. Genius.Today, as I continue to marvel at what I'm learning from each demo that I do and the feedback that I hear, I realize how much I don't yet know about the solution people need. But I also realize that I'm pretty far along in understanding what's needed. It's funny how often they'll ask a question just as I'm getting to that feature, and how often they'll remark that it flows really well. I can't take the credit for any of that. It's just me listening to a bunch of smart people telling me how I can help them succeed better. Always beware working with the person who refuses to admit ignorance. You'll pay dearly for it later. |
|
|
|
|
|
|
|
