Someone "liked" the DataClass homepage on Facebook. I wish I could figure out who it was. It's very flattering as it was not particularly solicited.
Anywho. Today is the last day before tomorrow and tomorrow is the first day of the DataClass beta. I'm leaving registration open until the 10th. If you don't get a chance to get involved in this beta, there will be another chance in August if you are a Java programmer or work with Java programmers who use a database you maintain.
Wednesday, June 30, 2010
Monday, June 28, 2010
What Can We Learn about Agility from the Pyramids?
In response to http://whitewaterprojects.com/2010/06/28/were-pyramids-the-first-iterative-development/.
The author makes a good point. In all likelihood the pyramids were built that way and, again in all likelihood, it did have the effect of a pyramid being ready whenever a pharaoh died. The way these facts are presented tells us something about a lot of things. Not the least interesting of which is the ever-present and ever-intriguing issue of perspective.
On the surface, this story tells us how Agility helped the people building tombs for pharaohs in ancient Egypt. Another layer down, it tells us about how large groups of people organize to become agile. Deeper still is a story of motivations and perspective. Think of this as a practicality sandwich on philosophy bread. The outer layers are important but I'm going to focus on the meat.
How did the ancient Egyptians learn to become Agile when it took us so many decades of lean thinking? It's amazing, really.
In the words of Chazz Michael Michaels, it's mind-bottling. You know, when things are so crazy it gets your thoughts all trapped, like in a bottle?
So while you are sitting there being all astounded by the wisdom of the ancients, let me just add this one little piece of info to the puzzle:
There were no massive cranes back then. There were no steel girders. There was no such thing as temporary scaffolding that could suspend one of those stones for a substantial period of time.
Knowing that, the question has to be asked. How else would they have built a pyramid? What structural, architectural, or engineering tools could they have used to do anything else but build it in shells?
Once you answer those questions, it becomes apparent that they had to be agile. They had no alternative. There were no tools available that would accommodate a big-batch approach in the first place. Being ready to bury a pharaoh who died before his time probably was not even on anybody's mind.
...at least until the first time one died young. Then, maybe, someone said "Hey! It's really handy we've been building these tombs this way, now we can just drop him off in the center and start working on the next guy's pyramid!"
There is no evidence that the ancient Egyptians' agility was a consequence of their wisdom or foresight. Quite the opposite, agility was mandated by the context in which the supposedly agile people did their work. There is a nugget of wisdom in that fact.
I think it is this: People are not naturally agile. Don't try to control the person, instead control the context in which they work. Make agility easier than the alternative and the people will do the hard part of the transition for you.
The author makes a good point. In all likelihood the pyramids were built that way and, again in all likelihood, it did have the effect of a pyramid being ready whenever a pharaoh died. The way these facts are presented tells us something about a lot of things. Not the least interesting of which is the ever-present and ever-intriguing issue of perspective.
On the surface, this story tells us how Agility helped the people building tombs for pharaohs in ancient Egypt. Another layer down, it tells us about how large groups of people organize to become agile. Deeper still is a story of motivations and perspective. Think of this as a practicality sandwich on philosophy bread. The outer layers are important but I'm going to focus on the meat.
How did the ancient Egyptians learn to become Agile when it took us so many decades of lean thinking? It's amazing, really.
So while you are sitting there being all astounded by the wisdom of the ancients, let me just add this one little piece of info to the puzzle:
There were no massive cranes back then. There were no steel girders. There was no such thing as temporary scaffolding that could suspend one of those stones for a substantial period of time.
Knowing that, the question has to be asked. How else would they have built a pyramid? What structural, architectural, or engineering tools could they have used to do anything else but build it in shells?
Once you answer those questions, it becomes apparent that they had to be agile. They had no alternative. There were no tools available that would accommodate a big-batch approach in the first place. Being ready to bury a pharaoh who died before his time probably was not even on anybody's mind.
...at least until the first time one died young. Then, maybe, someone said "Hey! It's really handy we've been building these tombs this way, now we can just drop him off in the center and start working on the next guy's pyramid!"
There is no evidence that the ancient Egyptians' agility was a consequence of their wisdom or foresight. Quite the opposite, agility was mandated by the context in which the supposedly agile people did their work. There is a nugget of wisdom in that fact.
I think it is this: People are not naturally agile. Don't try to control the person, instead control the context in which they work. Make agility easier than the alternative and the people will do the hard part of the transition for you.
Saturday, June 26, 2010
Frustrated by SlideShare
SlideShare has some cool features and I really like the idea. However, I do find its user experience maddening. Not that I am the king of user experience or anything... the Hexagon Software website is evidence enough of that.
Still. I'm one guy with a day job. SlideShare appears to be a company that does this as a reason to exist. Mostly the problems I have come from two things:
Still. I'm one guy with a day job. SlideShare appears to be a company that does this as a reason to exist. Mostly the problems I have come from two things:
- Delays
- Unclear directives
Delays
I get that it takes time to do something like process a document into a SlideCast. What I don't get is why there is no indication to me that I should be waiting. Frequently, SlideShare will tell me something is "done" but it does not appear to actually be done, yet. There is no way for me to determine whether something went wrong or everything is fine except to wait.
Unclear Directives
Generally speaking, buttons don't do what I think they should do. This is especially true of file uploads. Am I uploading a video? A slide deck? A document? Why, when I try to upload a video, does the Open dialog not show videos but, when I try to upload a slide deck, I have to sift through a bunch of videos?
What Can We Learn?
In reality, these are all just examples of poor feedback. A simple note saying "Your new document is in the final stages of processing. Please be patient." Would save a lot of pain and suffering. A few extra developer hours on their upload technology would save decades in user time over the course of the next year.
Friday, June 25, 2010
Why & how DataClass can facilitate Agile database development
I've released another video on the topic of DataClass. This time I go over what the problems related to database development are and how DataClass helps you resolve them.
Wednesday, June 23, 2010
DataClass 1.0 Beta Program Impending
Well, I'm excited to say that the beta program has reached critical mass in terms of registrants so we are definitely on for July.
Make sure you sign up here if you are interested.
I'm really excited about the opportunity to build a new product using what I know about business, product, and software development today. DataClass is something that is a big deal for me because it is the result of nearly half a decade of accumulated knowledge. Everything I learnt we shouldn't do with DataConstructor, I made sure isn't done by DataClass. All the most important things I wished I could have are in DataClass.
Moreover, it represents a whole new way of thinking and of working with databases. The vision I've been pushing in my courses and in my writings is now facilitated by a single logical document compiled by a single tool.
I look forward to getting real feedback and releasing the initial version of DataClass and I hope you do, too.
Make sure you sign up here if you are interested.
I'm really excited about the opportunity to build a new product using what I know about business, product, and software development today. DataClass is something that is a big deal for me because it is the result of nearly half a decade of accumulated knowledge. Everything I learnt we shouldn't do with DataConstructor, I made sure isn't done by DataClass. All the most important things I wished I could have are in DataClass.
Moreover, it represents a whole new way of thinking and of working with databases. The vision I've been pushing in my courses and in my writings is now facilitated by a single logical document compiled by a single tool.
I look forward to getting real feedback and releasing the initial version of DataClass and I hope you do, too.
Saturday, June 19, 2010
DataClass Case Study #1: Solving the Duplication Problem
I've posted a short (12 minute) video on SlideShare that shows how you can use DataClass to eliminate duplication between the documents you used to define your database and your .net database client. I intend to hit Java in the near future.
Here is a link to the video.
Stay tuned and be sure to sign up for the beta if you want to be a part of it.
Here is a link to the video.
Stay tuned and be sure to sign up for the beta if you want to be a part of it.
DataClass 1.0 Beta Program Open
The DataClass 1.0 Beta program is now open. DataClass is the next generation of DataConstructor technology. It is smaller, faster, and does a heck of a lot more.
If you are interested, the sign-up form can be found below. You will get a beta license to the product to be used over the course of the month of July. You will then get a survey to fill out in August. When you fill out the survey, you will get a complementary 1-seat license to DataClass as a thank you.
Click here to go to the beta sign-up page.
Monday, June 07, 2010
Two Customers
In response to http://whitewaterprojects.com/2010/06/04/who-is-your-cutomer/.
I respectfully disagree with the concept of a "technical customer" in addition to a "business customer." It may just be a semantics thing but I think it's important to keep the customer's place special.
The customer is the customer. For the team closest to the customer, that is not difficult to see. For teams "behind" the teams on the "surface" of an organization, it gets a little cloudier. I think it makes more sense to think of the intervening teams between yours and the customer as downstream work-cells. As such, they have the power to specify what an upstream work-cell builds in the moment.
The mental difference, however, is that they are not considered customers when your organization is working to optimize the whole.
Now, if there are two kinds of customer, I would say that there is a business customer and a process customer. That is, you can spend time delivering value to your actual customers, or you can spend time increasing your organizations capacity or lowering its cost.
The process customer is going to be interested in any project that eliminates waste. This might be traditional process projects like training in the latest methodology. This might be the acquisition of a tool. This might be something we don't think of as process but that plays heavily into it, like refactoring or covering legacy code it tests.
The business customer just wants what it wants.
I respectfully disagree with the concept of a "technical customer" in addition to a "business customer." It may just be a semantics thing but I think it's important to keep the customer's place special.
The customer is the customer. For the team closest to the customer, that is not difficult to see. For teams "behind" the teams on the "surface" of an organization, it gets a little cloudier. I think it makes more sense to think of the intervening teams between yours and the customer as downstream work-cells. As such, they have the power to specify what an upstream work-cell builds in the moment.
The mental difference, however, is that they are not considered customers when your organization is working to optimize the whole.
Now, if there are two kinds of customer, I would say that there is a business customer and a process customer. That is, you can spend time delivering value to your actual customers, or you can spend time increasing your organizations capacity or lowering its cost.
The process customer is going to be interested in any project that eliminates waste. This might be traditional process projects like training in the latest methodology. This might be the acquisition of a tool. This might be something we don't think of as process but that plays heavily into it, like refactoring or covering legacy code it tests.
The business customer just wants what it wants.
Subscribe to:
Posts (Atom)