Everyone understand what MVC does and why, well probably not, but they think they do. I'm thinking about a MACRO MVC. Where the mashup is the Controller and the View is the visualizer/Web2.0 interface.
This is my pretty picture of what I mean and why it's important. It's not only about how quickly you can do a mashup, but how much time you have spent doing the traditional IT development and why this can only work in a light weight framework such as Mashups.
Mashup Model
Friday, August 7, 2009
Monday, July 13, 2009
The Muse about Mashups
So how does the mashup concept fit in the world of self actualized software developers? Probably better to explain something about mashups, or what I like calling:
Post Consumer
Intuitively Presented
Coincidental
Aggregated
Real Time
Data
OK, maybe it's a stretched Geeky Acronym for PICARD, but it's better than my last one:
PASTY: Platform for Automation of Secure Flight Testing, Yes.
Post Consumer - This data was already presented, cleansed, provisioned, secured from other applications. In other words it's already showing up on someone's desktop, in the form of a web application, RSS feed, a physical report, email, WSDL based application, etc. But it's fragmented currently. The mashup's job is to combine things, intelligently, more on that later.
Intuitively Presented - The real reason the Web is a breakthrough is because it's easy to understand, it's not the technology it is what the end user/consumer can do with the information. If they need a computer science degree, they probably will never do anything with it, because they won't understand it. The Web 2.0 type of interfaces that are intuitive, rich and powerful, means you can get the data you want and you will understand what you are looking at.
Coincidental - This is probably a weaker word than I really want, probably correlated sounds better. Basically a few data points alone mean little, but many points show a picture. You remember geometry, a point is a point, two points define a line, 3 points defines a plane, and 284 points draws a picture of Britney Spears!!!
Aggregated - So before you can correlate, and make things coincident, you have to have pull it from different sources. Public and private sources, but remember these can be non-traditional source such as firewall log files, proxy server logs, the type of things that generally don't get monitored.
Real Time - Information has a shelf-life just like fresh fruit, not like a Twinkies. The older something is, the more it tastes bad! So a mashup, unlike a business intelligence effort is all about what is happening now, not in the past.
Data - Well, without out some raw elemental information there is no point... In today's IT world there is no lack of data, the issue is rather a signal to noise ratio and understanding what you are looking at and then knowing what to do with it.
This is the world of a 1st order enterprise mashup with its mission to quickly find real time trends and assist businesses and getting to an actionable position as quickly and as cheaply as you can. That seems to be where the state-of-the-art mashups are now.
Post Consumer
Intuitively Presented
Coincidental
Aggregated
Real Time
Data
OK, maybe it's a stretched Geeky Acronym for PICARD, but it's better than my last one:
PASTY: Platform for Automation of Secure Flight Testing, Yes.
Post Consumer - This data was already presented, cleansed, provisioned, secured from other applications. In other words it's already showing up on someone's desktop, in the form of a web application, RSS feed, a physical report, email, WSDL based application, etc. But it's fragmented currently. The mashup's job is to combine things, intelligently, more on that later.
Intuitively Presented - The real reason the Web is a breakthrough is because it's easy to understand, it's not the technology it is what the end user/consumer can do with the information. If they need a computer science degree, they probably will never do anything with it, because they won't understand it. The Web 2.0 type of interfaces that are intuitive, rich and powerful, means you can get the data you want and you will understand what you are looking at.
Coincidental - This is probably a weaker word than I really want, probably correlated sounds better. Basically a few data points alone mean little, but many points show a picture. You remember geometry, a point is a point, two points define a line, 3 points defines a plane, and 284 points draws a picture of Britney Spears!!!
Aggregated - So before you can correlate, and make things coincident, you have to have pull it from different sources. Public and private sources, but remember these can be non-traditional source such as firewall log files, proxy server logs, the type of things that generally don't get monitored.
Real Time - Information has a shelf-life just like fresh fruit, not like a Twinkies. The older something is, the more it tastes bad! So a mashup, unlike a business intelligence effort is all about what is happening now, not in the past.
Data - Well, without out some raw elemental information there is no point... In today's IT world there is no lack of data, the issue is rather a signal to noise ratio and understanding what you are looking at and then knowing what to do with it.
This is the world of a 1st order enterprise mashup with its mission to quickly find real time trends and assist businesses and getting to an actionable position as quickly and as cheaply as you can. That seems to be where the state-of-the-art mashups are now.
Friday, July 10, 2009
The Maslow's/Eoyang's Hierarchy of Software Development
You know the theory... You start with basic needs and you build and build until you get to self actualization, when great things happen because you have all the little things taken care of? Well I believe in that as it applies to people but also in Software Development. OK here is the Pyramid for people:
.
Well I think it's a mistake to take one model and apply it 100% to another situation because it never fits 100% - but that's an entirely different discussion, for another time - remind me - Iterated Prisoner's Dilemma.
But here's how I think a similar pyramid exists for software development.
.
Well I think it's a mistake to take one model and apply it 100% to another situation because it never fits 100% - but that's an entirely different discussion, for another time - remind me - Iterated Prisoner's Dilemma.
But here's how I think a similar pyramid exists for software development.
| Level | You Are | Action Time | Role | % of Time | Tasks/Skills | Artifact Examples |
| Strategy | Thinking | 3-18 months | Executive | 10% | Enterprise Architecture, Business Requirements, Strategy to Tactics decomposition, ROI | Business Plan, Yearly Financial Report |
| Tactics | Planning | 1-6 months | Manager | 25% | SDLC, Design, Quality, Metrics, Process, Coordination, Tactics to Implementation decomposition. | Project Plan, Design Document, Lessons Learned, Defect Reports |
| Implementation | Doing | 0-3 months | Developer /Analyst | 65% | Programming, Hardware, Software, Integration, Testing, Documentation, Deploying, Task Tracking | Application Code, System Infrastructure, Documentation |
Thursday, July 9, 2009
A New Direction
I have recently left the traditional world of software development. It seems I can only stand working in a largely dysfunctional environment for so long and then I am tempted to explode. So I left my position at TSA as the software development manager of Secure Flight.
I am now a proud employee of Jackbe. It's a different model for software development, for a targeted type of application. I'm trying to understand how the tools, philosophy and processes will meld together to create a better world. What are the pros and cons to this approach? I'll be posting my thoughts here.
My first thought is along these lines from Information Week.
But that's really not starting at the beginning.
I am now a proud employee of Jackbe. It's a different model for software development, for a targeted type of application. I'm trying to understand how the tools, philosophy and processes will meld together to create a better world. What are the pros and cons to this approach? I'll be posting my thoughts here.
My first thought is along these lines from Information Week.
But that's really not starting at the beginning.
Tuesday, August 21, 2007
The myth of plausable deniability
Have you ever been in a status meeting, going over the action items. You get to one item, which is to call an organization/person and check on something. The person assigned to that task is asked to report on it. You ask him/her, "can you give me a status, it was due today." And the person says, Umm, oh yea, Right, I, umm I called them yesterday, but they weren't in and I got their voicemail, so I'm waiting for them to get back to me.
Hello? Lying? and the sad truth is, although it could be true, everyone knows it's not true. So why say it and insult the people at the table by lying to them and then thinking that they are buying the lie. I'm not sure what is worse.
Wouldn't you rather hear, "You know, I'm sorry, I completely vegged that and will call them as soon as I get out of that meeting and will email everyone the update on the task by the end of the day."
Now granted you don't want to hear that all the time, but otherwise you are perpetuating a lie, and that is no way to conduct a collaborative project. If it's OK to lie then where does that stop? If you can't trust each other, I guess you better get out the contract documents. And then you better get out the signed off Requirements docs and the User acceptance docs. OHHHHHH, is that where all of that comes from? Yeah, pretty much. If you don't trust people then you try to tie them down with documentation so that everything is crystal clear. But in reality, things change, and you don't always have time to document everything, why things changed, and get approval from 10 layers of management and contracts etc, for those changes.
But, if you trust each other, it's OK.
And how do you trust each other? You do what you said you were going to do and you DO NOT LIE. So if you tried to do everything that you said you were going to do and you failed, you admit it and try to move forward with lessons learned.
Come on now guys, we aren't 8 years old telling our Mom's we didn't break the dish that it just fell off the table by itself. Isn't it time we grew up an acted like professionals? Wouldn't that be refreshing?
Sorry Client X, I screwed up, This is what happened, this is why it happened, this is what I'm going to do to fix it and this is what I'm going to do to make sure it's not going to happen again.
Is it that hard? And which one as a client would you rather hear? OK I guess you can file that one under collaborative necessities of trust.
I have done it many times, I deleted the entire production database once, accidentally. As soon as I realized I did it, I sent an email out to a broad audience, explaining exactly what I had done. All that did was build trust because I was open when it was tough to be open. The client? made a joke about it and asked when the data would be back up.
Treat clients like adults and they might just act like adults!
Hello? Lying? and the sad truth is, although it could be true, everyone knows it's not true. So why say it and insult the people at the table by lying to them and then thinking that they are buying the lie. I'm not sure what is worse.
Wouldn't you rather hear, "You know, I'm sorry, I completely vegged that and will call them as soon as I get out of that meeting and will email everyone the update on the task by the end of the day."
Now granted you don't want to hear that all the time, but otherwise you are perpetuating a lie, and that is no way to conduct a collaborative project. If it's OK to lie then where does that stop? If you can't trust each other, I guess you better get out the contract documents. And then you better get out the signed off Requirements docs and the User acceptance docs. OHHHHHH, is that where all of that comes from? Yeah, pretty much. If you don't trust people then you try to tie them down with documentation so that everything is crystal clear. But in reality, things change, and you don't always have time to document everything, why things changed, and get approval from 10 layers of management and contracts etc, for those changes.
But, if you trust each other, it's OK.
And how do you trust each other? You do what you said you were going to do and you DO NOT LIE. So if you tried to do everything that you said you were going to do and you failed, you admit it and try to move forward with lessons learned.
Come on now guys, we aren't 8 years old telling our Mom's we didn't break the dish that it just fell off the table by itself. Isn't it time we grew up an acted like professionals? Wouldn't that be refreshing?
Sorry Client X, I screwed up, This is what happened, this is why it happened, this is what I'm going to do to fix it and this is what I'm going to do to make sure it's not going to happen again.
Is it that hard? And which one as a client would you rather hear? OK I guess you can file that one under collaborative necessities of trust.
I have done it many times, I deleted the entire production database once, accidentally. As soon as I realized I did it, I sent an email out to a broad audience, explaining exactly what I had done. All that did was build trust because I was open when it was tough to be open. The client? made a joke about it and asked when the data would be back up.
Treat clients like adults and they might just act like adults!
Thursday, June 28, 2007
Enough with what doesn't work?
So? are you frustrated now that all I seem to be doing is railing on all the things that don't work, which is a lot easier than saying what does work? Ok, fair enough. What does work.
This is going to sound silly but here it is. What does work is:
communication, trust, collaboration, and mutually beneficial motivation.
It sounds silly, but be honest, go through this list and tell me if everyone on the project team would say you have those 4 things?
Communication - I know, everyone says that's the most important thing, but in software development, it's not the same as building a skyscraper or a submarine. How so? it's not because they aren't as complex or as big, though that can be part of it. The issue is more that you can't and don't know what you are going to have when you start. There is an evolutionary process that stretches the human mind and creativity and business process, and solutions mindset when you develop software. What you have in the end of a successful project is never what you started out to build, specifically. Abstractly, sure. You want a website, you get a website. But of the 12 things you said you had to have, during the course of the project only 7 remain and you've picked another 7 that were not on the list because you've learned. You aren't dumb, as a client, you just didn't see it all unfold until it started unfolding, at that point it made sense. So the type of communication that you need is not static at all, it's dynamic. And it has these key components:
1) Task/deliverable bounded - don't worry about talking about your philosophy of how to hep users, or what the organization should be doing in 2 years, worry about what the business rules are for the 4th screen, what are the options, what are the impacts and who is going to implement them.
2)Timely and direct - avoid the urge to put things off - action items, meetings, email messages can be a form of procrastination. Just get it done. You need an answer, don't write down that you need an answer, get on the phone or walk down the hall and get an answer. The email that you write should immortalize the discussion so no one forgets and so that others can be benefiting from the knowledge of your discussion. It's all about how quickly you can get enough information to make a decision and move forward, 5 minutes time on task might take 2 weeks if you don't just get in someone's face and ask the question.
3)Solutions oriented, do not own the issue or problem and don't make anyone else do that either. Seek a common solution together. In order to do that, remember, you have to correctly identify the problem and accept that the problem exists. That sounds a lot easier than you think. I bet you can think of issues that are driving you nuts that others would deny are problems at all. Why? probably because they own the problem and therefore are in denial. Do not meet to meet, meet to work out a deliverable, walk through the deliverable during the meeting, when you are done with the meeting, you have done some of the work, rather than havin a huge list of t0-dos which you are not always going to finish.
4) Communications are part of the teams collective consciousnesses. Don't keep the conclusion of the discussion to yourself, share it with everyone who might benefit from it so that you essentially can put the conclusion in the hall of fame and move on to the next discussion. Otherwise the audience is only partially represented and the value of the communication is dramatically reduced.
5) Focused and appropriately audienced (ha I just made that word up, do you like it?) - Do not have discourses with people who have no authority, input, expertise or ability to influence either before or after the discussion. If you start a conversation, on any media, you know should know what you expect to get out of the discussion, or you should not have started.
This is going to sound silly but here it is. What does work is:
communication, trust, collaboration, and mutually beneficial motivation.
It sounds silly, but be honest, go through this list and tell me if everyone on the project team would say you have those 4 things?
Communication - I know, everyone says that's the most important thing, but in software development, it's not the same as building a skyscraper or a submarine. How so? it's not because they aren't as complex or as big, though that can be part of it. The issue is more that you can't and don't know what you are going to have when you start. There is an evolutionary process that stretches the human mind and creativity and business process, and solutions mindset when you develop software. What you have in the end of a successful project is never what you started out to build, specifically. Abstractly, sure. You want a website, you get a website. But of the 12 things you said you had to have, during the course of the project only 7 remain and you've picked another 7 that were not on the list because you've learned. You aren't dumb, as a client, you just didn't see it all unfold until it started unfolding, at that point it made sense. So the type of communication that you need is not static at all, it's dynamic. And it has these key components:
1) Task/deliverable bounded - don't worry about talking about your philosophy of how to hep users, or what the organization should be doing in 2 years, worry about what the business rules are for the 4th screen, what are the options, what are the impacts and who is going to implement them.
2)Timely and direct - avoid the urge to put things off - action items, meetings, email messages can be a form of procrastination. Just get it done. You need an answer, don't write down that you need an answer, get on the phone or walk down the hall and get an answer. The email that you write should immortalize the discussion so no one forgets and so that others can be benefiting from the knowledge of your discussion. It's all about how quickly you can get enough information to make a decision and move forward, 5 minutes time on task might take 2 weeks if you don't just get in someone's face and ask the question.
3)Solutions oriented, do not own the issue or problem and don't make anyone else do that either. Seek a common solution together. In order to do that, remember, you have to correctly identify the problem and accept that the problem exists. That sounds a lot easier than you think. I bet you can think of issues that are driving you nuts that others would deny are problems at all. Why? probably because they own the problem and therefore are in denial. Do not meet to meet, meet to work out a deliverable, walk through the deliverable during the meeting, when you are done with the meeting, you have done some of the work, rather than havin a huge list of t0-dos which you are not always going to finish.
4) Communications are part of the teams collective consciousnesses. Don't keep the conclusion of the discussion to yourself, share it with everyone who might benefit from it so that you essentially can put the conclusion in the hall of fame and move on to the next discussion. Otherwise the audience is only partially represented and the value of the communication is dramatically reduced.
5) Focused and appropriately audienced (ha I just made that word up, do you like it?) - Do not have discourses with people who have no authority, input, expertise or ability to influence either before or after the discussion. If you start a conversation, on any media, you know should know what you expect to get out of the discussion, or you should not have started.
Wednesday, June 27, 2007
Common Misconception
Have you ever heard this: We don't have time to document our code? We just need more time. I know I'm supposed to be doing a project management plan, but I just don't have the time. If you want me to do that the entire project is going to take a lot longer.
See here is the reality. People don't do things if they don't pay off, they may start but they quickly stop if it doesn't pay off. On the otherhand, if things work they will keep doing them.
You will find I like to explain things with analogies because human beings understand object models and we actually have a lot of complex object models in our head that have taken long time to develop and it turns out that most object models are more the same than different. I recognize that they aren't 100% the same, but hopefully enough to get the point across.
Ok so here's my first analogy. I really want to make it with that woman. But I don't have time to get a condom, so I'll skip it. Well now, what if you end up paying the price for that time savings, either in becoming a potential father or getting or giving a disease. Is it a pain to do? yes, but it pays off, so you do it.
Is software documentation like a prophylacitic for your system? could be, if it's the right kind of documentation. OK maybe I better stop with that analogy or it will get people really on my case. But hopefully the point is made. When things pay off, however inconvenient, you do them, if they don't pay off you find excuses that usually stick and you don't do them.
See here is the reality. People don't do things if they don't pay off, they may start but they quickly stop if it doesn't pay off. On the otherhand, if things work they will keep doing them.
You will find I like to explain things with analogies because human beings understand object models and we actually have a lot of complex object models in our head that have taken long time to develop and it turns out that most object models are more the same than different. I recognize that they aren't 100% the same, but hopefully enough to get the point across.
Ok so here's my first analogy. I really want to make it with that woman. But I don't have time to get a condom, so I'll skip it. Well now, what if you end up paying the price for that time savings, either in becoming a potential father or getting or giving a disease. Is it a pain to do? yes, but it pays off, so you do it.
Is software documentation like a prophylacitic for your system? could be, if it's the right kind of documentation. OK maybe I better stop with that analogy or it will get people really on my case. But hopefully the point is made. When things pay off, however inconvenient, you do them, if they don't pay off you find excuses that usually stick and you don't do them.
Subscribe to:
Posts (Atom)
