Monday, December 31, 2012
Reading time #4!
- The good people at gosquared.com got some nice tips for node.js:
https://engineering.gosquared.com/10-vital-aspects-of-building-a-node-js-application
- Stats from 2012 are here. Samsung sells a lot more phones than Apple. Twice.
- If you're a geek, this guy is hilarious.
- "2013 will be all about the ecosystems, not just the hardware": Here are some trends to watch for, curtesy of techradar.
And, finally, have a happy 2013!
Wednesday, December 26, 2012
The instant presentation effect
This week I've attended a strategic brainstorming session.
During this session, we divided our group into smaller groups, each with the task of analysing strengths and weaknesses of a certain solution.
While most of the groups wrote down their notes in their notebooks, and presented their outcome while reading from it, I took a laptop, and jotted down the team's effort into a 6 slide power point presentation in our company's template:
During this session, we divided our group into smaller groups, each with the task of analysing strengths and weaknesses of a certain solution.
While most of the groups wrote down their notes in their notebooks, and presented their outcome while reading from it, I took a laptop, and jotted down the team's effort into a 6 slide power point presentation in our company's template:
- Topic slide - Solution name
- Solution main principals
- Customer analysis
- Strengths
- Weaknesses
- End slide ('Thank you').
Coming up with a structured presentation was far more effective than reading your conclusions. The impact was immediate, and the message was clear.
And it wasn't more complicated than writing down your ideas.
Give this method a shot the next time you brainstorm. Your message might become much more effective.
For more ideas about how to write effective presentations, my friend Jan Schultink has a great blog (And presentation design company :)
For more ideas about how to write effective presentations, my friend Jan Schultink has a great blog (And presentation design company :)
Friday, December 21, 2012
Facebook stabs spam
The war on spam has failed. Though email providers like Google and Microsoft get a relatively good spam detection rate, there will never be a 100% success rate. And these guys are getting smarter.
Even Facebook were not left out, and many people get spam sent to them (check your 'other' message box...)
Well now Facebook are making a stand against spam, by charging 1$ per message to someone you don't know.
I think that's actually nice.
Tuesday, December 18, 2012
Mobile web and sandboxing
I've had a few discussions in this blog about mobile web vs. native in app development.
One of the major problems with creating a mobile web app was performance. When an app needs to display a large list of items, rendering a huge DOM tree with lots of layers causes app performance degradation, resulting in poor user experience.
Well - The guys at sencha came up with a neat idea - 'Sandboxing', which means fragmenting your content items into small iframes.
The basic motivation behind this is that it's easier for the browser to render lots of smaller DOM frames than rendering one huge DOM tree. With multi core processors (And supporting OSs like iOS5/ Android 4 and above), this approach becomes even more effective.
You can read more about it here.
[Thanks Danny Livshits for the link]
One of the major problems with creating a mobile web app was performance. When an app needs to display a large list of items, rendering a huge DOM tree with lots of layers causes app performance degradation, resulting in poor user experience.
Well - The guys at sencha came up with a neat idea - 'Sandboxing', which means fragmenting your content items into small iframes.
The basic motivation behind this is that it's easier for the browser to render lots of smaller DOM frames than rendering one huge DOM tree. With multi core processors (And supporting OSs like iOS5/ Android 4 and above), this approach becomes even more effective.
You can read more about it here.
[Thanks Danny Livshits for the link]
Monday, December 10, 2012
Google services outage and android crashes
Yesterday afternoon, I've started experiencing hiccups in my Galaxy Nexus (Running 4.2.1).
Crashes, phone getting stuck without provocation from my side, sluggish performance.
Turns out Google's services had a major disruption yesterday.
Coincidence? I don't think so. Problematic? Very much. But this is what we sign for, and this is why Google's devices are so cheap... Actually, Apple's devices are the same in terms of cloud dependency (Siri, iCloud etc.), but you pay more...
In the meantime, legislation is having it's way with Apple's software patents. That is good news for ANYONE creating software these days. (Read the last paragraph of this post for more).
Crashes, phone getting stuck without provocation from my side, sluggish performance.
Turns out Google's services had a major disruption yesterday.
Coincidence? I don't think so. Problematic? Very much. But this is what we sign for, and this is why Google's devices are so cheap... Actually, Apple's devices are the same in terms of cloud dependency (Siri, iCloud etc.), but you pay more...
In the meantime, legislation is having it's way with Apple's software patents. That is good news for ANYONE creating software these days. (Read the last paragraph of this post for more).
Thursday, November 1, 2012
Of products and projects
There are several approaches, when starting your own startup.
Most startups these days are using the approach of 'we build a great product, and users will come'. They begin with a vision, or a problem that needs a solution, and then build their service.
Some startups, however, take a different approach. These startups work mostly in the enterprise (B2B) arena. They actually begin as a one project company, and build their product for one customer. Then they refine, it as more customers come in.
The product approach is more common, because you don't have to do much as an entrepreneur - Just explain your vision, and if it makes sense (And you have some connections), you'll get some funding to begin. You can sprint your product, and then launch, and hope (Or use PR/ Community managers/ Marketing) to generate buzz and acquire users. Sometimes (Like, um, a lot of successful social companies) the product becomes a hit, and then you worry (Or not... Like Instagram) about monetizing it.
The project approach is harder. You need to partner with one (Or few more) customers, which will also pay you for your service (That doesn't necessarily exist yet). And then you have to deal with them, and all the growing pains of sorting out the problems. However, you might not need funding at all - This means, with current valuations and VCs pressing entrepreneurs desperate to keep their dream alive, that you might not need that phase at all. After you gain enough customers, you'll have a sense of what the market needs, and you can actually build a working product.
And then there's another approach.
Find a targeted person (Or small audience) for your idea, and build the product for him. (Or her... I'm using male for comfort reasons only) Treat him as a paying customer. Each one of your audience should be treated as a 'project'. Then you can actually get the real sense of what your product should be.
Finally, here's a great product that succeeded mostly because the developers that built it did it for a great audience: Themselves. I wrote about MongoDB in previous posts, here's an explanation of what makes this product so popular:
http://blog.mongolab.com/2012/08/why-is-mongodb-wildly-popular/
Most startups these days are using the approach of 'we build a great product, and users will come'. They begin with a vision, or a problem that needs a solution, and then build their service.
Some startups, however, take a different approach. These startups work mostly in the enterprise (B2B) arena. They actually begin as a one project company, and build their product for one customer. Then they refine, it as more customers come in.
The product approach is more common, because you don't have to do much as an entrepreneur - Just explain your vision, and if it makes sense (And you have some connections), you'll get some funding to begin. You can sprint your product, and then launch, and hope (Or use PR/ Community managers/ Marketing) to generate buzz and acquire users. Sometimes (Like, um, a lot of successful social companies) the product becomes a hit, and then you worry (Or not... Like Instagram) about monetizing it.
The project approach is harder. You need to partner with one (Or few more) customers, which will also pay you for your service (That doesn't necessarily exist yet). And then you have to deal with them, and all the growing pains of sorting out the problems. However, you might not need funding at all - This means, with current valuations and VCs pressing entrepreneurs desperate to keep their dream alive, that you might not need that phase at all. After you gain enough customers, you'll have a sense of what the market needs, and you can actually build a working product.
And then there's another approach.
Find a targeted person (Or small audience) for your idea, and build the product for him. (Or her... I'm using male for comfort reasons only) Treat him as a paying customer. Each one of your audience should be treated as a 'project'. Then you can actually get the real sense of what your product should be.
Finally, here's a great product that succeeded mostly because the developers that built it did it for a great audience: Themselves. I wrote about MongoDB in previous posts, here's an explanation of what makes this product so popular:
http://blog.mongolab.com/2012/08/why-is-mongodb-wildly-popular/
Saturday, October 20, 2012
The Microsoft manoeuvre
Well... October is here, and the three big ones (Google/ Apple/ Microsoft) are rolling new devices, just in time for the holidays.
And while Apple and Google try to kip the lid on official announcements (But most of us already know what's in store...), Microsoft has been all out, revealing everything they've got months ago.
I wonder how it will play out, but the most obvious question for me, having moved in the past years from Microsoft environment (Developing enterprise applications and servers using C++) to Apple and open source environment (Developing web applications, web services and mobile apps), is: What would make me move back to Microsoft environment.
And, seriously, right now - The only answer is 'opportunity'. The fact that not too many people are going to make the switch back, and if you're the first one posting a product to a platform that will reach tens of millions of users (And it will), then there's money in it.
I'm going to see Steve Balmer speak at think next. It will be interesting to see how this evolves.
And while Apple and Google try to kip the lid on official announcements (But most of us already know what's in store...), Microsoft has been all out, revealing everything they've got months ago.
I wonder how it will play out, but the most obvious question for me, having moved in the past years from Microsoft environment (Developing enterprise applications and servers using C++) to Apple and open source environment (Developing web applications, web services and mobile apps), is: What would make me move back to Microsoft environment.
And, seriously, right now - The only answer is 'opportunity'. The fact that not too many people are going to make the switch back, and if you're the first one posting a product to a platform that will reach tens of millions of users (And it will), then there's money in it.
I'm going to see Steve Balmer speak at think next. It will be interesting to see how this evolves.
Sunday, October 7, 2012
If a tree falls...
In the forest, and no one is around to hear it does it make a sound?
If an independent developer publishes an app in the play store, and no one knows about it, will anyone download it?
Apparently, no.
And not only that, but when you search the app by exact name (No parenthesis), it would still appear 10th in search results.
This one's only regarding the play store, as the iTunes works differently.
Why is that? Could it be that Google promotes whoever pays them? I'll try to find out in the coming weeks.
The first step would be publishing a link to the app from this blog. (And if you want to teach your kid English letters, you should try this... It's free.)
Let's see how it does soon.
https://play.google.com/store/apps/details?id=com.myartichoke.youngletters
If an independent developer publishes an app in the play store, and no one knows about it, will anyone download it?
Apparently, no.
And not only that, but when you search the app by exact name (No parenthesis), it would still appear 10th in search results.
This one's only regarding the play store, as the iTunes works differently.
Why is that? Could it be that Google promotes whoever pays them? I'll try to find out in the coming weeks.
The first step would be publishing a link to the app from this blog. (And if you want to teach your kid English letters, you should try this... It's free.)
Let's see how it does soon.
https://play.google.com/store/apps/details?id=com.myartichoke.youngletters
Monday, September 24, 2012
Android app published... Some impressions.
After sorting out all the issues, along with some GUI tweaks, I finally got around to publish the application at the play store. (Get it here!)
Publishing process was a breeze - Compile the code in release mode, create a signing key, sign the app, upload (Along with promotional graphics), click publish, and that's it!
Seems like Google has the policy of 'garbage in/ garbage out', which means that rather than testing your app thoroughly (Like Apple do), which makes the whole publishing process take ~8-10 days, your app gets published instantly.
Which means that if an app sucks, Google counts on the crowd to rate the app accordingly. If it crashes a lot, or dead on arrival, you receive reports via the developer console, and can also 'unpublish' the app, update it as much as you want to etc.
Though I prefer the Apple way, which means that even if the app sucks, it still passes the bare minimum for usability, but I'm quite sure that this process helped android catch up the gap in 'total number of apps in the market' with iOS...
Publishing process was a breeze - Compile the code in release mode, create a signing key, sign the app, upload (Along with promotional graphics), click publish, and that's it!
Seems like Google has the policy of 'garbage in/ garbage out', which means that rather than testing your app thoroughly (Like Apple do), which makes the whole publishing process take ~8-10 days, your app gets published instantly.
Which means that if an app sucks, Google counts on the crowd to rate the app accordingly. If it crashes a lot, or dead on arrival, you receive reports via the developer console, and can also 'unpublish' the app, update it as much as you want to etc.
Though I prefer the Apple way, which means that even if the app sucks, it still passes the bare minimum for usability, but I'm quite sure that this process helped android catch up the gap in 'total number of apps in the market' with iOS...
Wednesday, September 12, 2012
Young Letters - Tales of the Android project.
I've started working on the Android version for my young letters application.
Because I'm working with phonegap, I was quite sure that Android porting would work seamlessly, and boy was I wrong...
Getting started was easy. Download Eclipse, Android plugin and SDKs, define the project and setup the phonegap plugin was quick and painless.
However, my code didn't work.
First off, the newest version of phonegap (2.0.0) has some bugs. Seems like after the major overhaul from 1.x, several things (Like playing sound...) were left undone. So I've decided to revert to the same phonegap version I'm using in iOS (1.8.1), which solved the problem.
Some code issues, like resource file paths (Base path on android is different) and HTML5 canvas behaving differently than iOS webview were solved.
Orientation handling is also different than iOS: With Android, it's harder to define orientation changes behaviours (Young Letters is only landscape, for now). In iOS it's a breeze, just select the supported orientations, and you're good to go.
And then I was left with one major issue, which I'm handling now: The variety of android devices and viewports. With iOS, there's only one variation of a screen. The width/ height ratios stay the same between iPhone versions (iPhone 5 supports that ratio as well by framing the extra inch), but with android devices, you have to implement an adaptive HTML view.
Though it was solved in the native environment, the major lesson I've learned was to use percentages and dynamic placements of buttons, rather than set layout (Like I'm doing on iOS).
Then I need to test it with several devices, and see that it works.
Finally there's the whole publishing process in the Google Play store, but we'll get to that once the app is ready!
Because I'm working with phonegap, I was quite sure that Android porting would work seamlessly, and boy was I wrong...
Getting started was easy. Download Eclipse, Android plugin and SDKs, define the project and setup the phonegap plugin was quick and painless.
However, my code didn't work.
First off, the newest version of phonegap (2.0.0) has some bugs. Seems like after the major overhaul from 1.x, several things (Like playing sound...) were left undone. So I've decided to revert to the same phonegap version I'm using in iOS (1.8.1), which solved the problem.
Some code issues, like resource file paths (Base path on android is different) and HTML5 canvas behaving differently than iOS webview were solved.
Orientation handling is also different than iOS: With Android, it's harder to define orientation changes behaviours (Young Letters is only landscape, for now). In iOS it's a breeze, just select the supported orientations, and you're good to go.
And then I was left with one major issue, which I'm handling now: The variety of android devices and viewports. With iOS, there's only one variation of a screen. The width/ height ratios stay the same between iPhone versions (iPhone 5 supports that ratio as well by framing the extra inch), but with android devices, you have to implement an adaptive HTML view.
Though it was solved in the native environment, the major lesson I've learned was to use percentages and dynamic placements of buttons, rather than set layout (Like I'm doing on iOS).
Then I need to test it with several devices, and see that it works.
Finally there's the whole publishing process in the Google Play store, but we'll get to that once the app is ready!
Thursday, September 6, 2012
Updates, new app, new gadget
A month and a half after I've decided to go for it, young letters hebrew is available.
The whole process was quite easy and smooth, though I've had one rejection due to iPad 2x mode compatibility.
Currently app has no analytics connected to it (Next month probably, along with feedback and some UI changes), and now let's see how it catches on.
http://itunes.apple.com/us/app/young-letters-hebrew/id552401430?ls=1&mt=8
English app version will follow up.
You might also see some new recommendations content gadget on my blog: My friends at engageya are providing these, which are very useful in driving more traffic to your (As well as other) blogs.
My other friends in dSero have a great solution for surpassing ad blockers, which is also crucial for the blogging community - Seems like there's a lot of new cool initiatives regarding the blogging community, which, in some ways, has replaced editorial journalism.
As for this blog, other than testing purposes, no commercials are expected in the near future.
The whole process was quite easy and smooth, though I've had one rejection due to iPad 2x mode compatibility.
Currently app has no analytics connected to it (Next month probably, along with feedback and some UI changes), and now let's see how it catches on.
http://itunes.apple.com/us/app/young-letters-hebrew/id552401430?ls=1&mt=8
English app version will follow up.
You might also see some new recommendations content gadget on my blog: My friends at engageya are providing these, which are very useful in driving more traffic to your (As well as other) blogs.
My other friends in dSero have a great solution for surpassing ad blockers, which is also crucial for the blogging community - Seems like there's a lot of new cool initiatives regarding the blogging community, which, in some ways, has replaced editorial journalism.
As for this blog, other than testing purposes, no commercials are expected in the near future.
Saturday, September 1, 2012
Click like an end user
I've recently had an emotional debate with developers about a design for a new content authoring product.
While we were building the UX and user flows, the developers have modeled their entities and data hierarchy, and wanted to propose a UX design that would parallel their data model and data flow.
That model, built like a nice view stack (Android style), meant that each entity would open a new view in order to be edited (With a 'back' button and a bread crumbs navigation), all due to the complexity of implementing an 'edit in place' editor for these entities.
While this solution has a very short time to market, scales well to new entity types, and looks cool, the argument that closed the debate was that the developers were not thinking like the end user.
As the end user edits hundreds of entities a day, 66% more clicks per entity and two more transitions (From one view down the stack and back up) would mean a lot more clicks and view changes, as well as would make work a lot more repetitive and tedious.
You can even describe the process, back to back:
Developer suggestion:
"Add entity, click to edit, view opens, edit, go back to view" (Repeat)
UX design:
"Add entity, click to edit (In place), edit" (Repeat)
Now multiply that by 1000s, and the difference is clear.
So next time developers come to you with the brilliant idea that might make the code be more maintainable and scalable, think about the end user as well... The last thing you'd want is that your version would be delivered in time and quality measures, but the users would hate it.
While we were building the UX and user flows, the developers have modeled their entities and data hierarchy, and wanted to propose a UX design that would parallel their data model and data flow.
That model, built like a nice view stack (Android style), meant that each entity would open a new view in order to be edited (With a 'back' button and a bread crumbs navigation), all due to the complexity of implementing an 'edit in place' editor for these entities.
While this solution has a very short time to market, scales well to new entity types, and looks cool, the argument that closed the debate was that the developers were not thinking like the end user.
As the end user edits hundreds of entities a day, 66% more clicks per entity and two more transitions (From one view down the stack and back up) would mean a lot more clicks and view changes, as well as would make work a lot more repetitive and tedious.
You can even describe the process, back to back:
Developer suggestion:
"Add entity, click to edit, view opens, edit, go back to view" (Repeat)
UX design:
"Add entity, click to edit (In place), edit" (Repeat)
Now multiply that by 1000s, and the difference is clear.
So next time developers come to you with the brilliant idea that might make the code be more maintainable and scalable, think about the end user as well... The last thing you'd want is that your version would be delivered in time and quality measures, but the users would hate it.
Friday, August 31, 2012
The most annoying flaw of the Galaxy nexus
Don't get me wrong. I love my Nexus phone. Android jellybean is great, performance is great, Google voice and Google now rule, however there's one annoying flaw.
One of the reasons I got this phone was its form factor. The 'no buttons' concept and smooth, curved design really appealed to me. But being a long fingered man, I tend to hit the 'home' button a lot when typing on he space bar.
This is quite annoying, as you need to reactivate the app. This even happened twice when typing this post...
Well, no one's perfect.
Sunday, August 19, 2012
In vacation... Notes about devices.
Having the need to be connected even during vacation, I took an iPad (3rd gen) alongside my new galaxy nexus phone.
After using those two devices for a while, here are some insights:
After using those two devices for a while, here are some insights:
- Android has caught up with iOS. Jelly bean, google voice, google now and other touches (app swapping, the software buttons, a great, huge screen) make my wife's iPhone 4s seem old.
- Even the form factor of the nexus (and the new s3 as well), the curved shapes, the soft buttons - make apple's device look old. Apple better come up with a killer iPhone 5, otherwise they're in trouble.
- Considering the fact that the next nexus device is also around the corner (rumored November), things seem interesting in the mobile market.
- I've finally understood the difference between the iPad 2 and the new iPad. I knew that the new screen is great, but only after moving from 2 to new, and working on the new for a while, you get to understand the meaning of a large retina screen. Everything looks analog. You can't see pixels. Amazing.
- I've played with the new galaxy note tablet, and though it's amazing fast, it's still no iPad. But android devices are catching up. Can't wait for a retina-like jellybean powered tablet.
- If the next MacBook air has retina, I'm in.
- Still no word from iTunes store about my app - submitted 8 days ago. Waiting sucks.
Wednesday, August 1, 2012
What to do with Google plus...
I stumbled onto a recent article in techcrunch, saying that Google+ is stopping new acquisitions into its product. Could it be the beginning of the end?
Google+ is actually a cool product. Looks great, has improved a lot over its 15 month life, but still doesn't seem to move people away from Facebook.
Maybe functionality and cool mobile UX is not enough? Though Facebook's UX sucks, both in website and especially mobile, what good is it if you can't find pictures of your girlfriend's friend wearing a thong in Thailand?
It's like Google has created the coolest theme park, but no one showed up, and those who came to the premiere out of curiosity, didn't come back. One of the main failures during the launch was the fact that I was unable to import all my Facebook connections in one click. That meant I had to start building my whole network from scratch - Why the hell would I wanna do that? (Or, even worse, build the network from my gmail, which had irrelevant connections, family and a lot of spam suggestions).
Another big reason might be because g+ is all dudes. That's actually a great article, saying that G+ was designed by, and for, Googlers, and Facebook was designed by, and for, college students (Looking to score...).
Now tell me, for real - Which network would you prefer?
Short update:
gmail just added hangouts to its chat dialog. Once again (Like in the good ol' buzz days), + is coming through the back door. Considering that gmail has ~400 million users, Google might already HAVE a social network. Sort of.
Google+ is actually a cool product. Looks great, has improved a lot over its 15 month life, but still doesn't seem to move people away from Facebook.
Maybe functionality and cool mobile UX is not enough? Though Facebook's UX sucks, both in website and especially mobile, what good is it if you can't find pictures of your girlfriend's friend wearing a thong in Thailand?
It's like Google has created the coolest theme park, but no one showed up, and those who came to the premiere out of curiosity, didn't come back. One of the main failures during the launch was the fact that I was unable to import all my Facebook connections in one click. That meant I had to start building my whole network from scratch - Why the hell would I wanna do that? (Or, even worse, build the network from my gmail, which had irrelevant connections, family and a lot of spam suggestions).
Another big reason might be because g+ is all dudes. That's actually a great article, saying that G+ was designed by, and for, Googlers, and Facebook was designed by, and for, college students (Looking to score...).
Now tell me, for real - Which network would you prefer?
Short update:
gmail just added hangouts to its chat dialog. Once again (Like in the good ol' buzz days), + is coming through the back door. Considering that gmail has ~400 million users, Google might already HAVE a social network. Sort of.
Friday, July 27, 2012
Mountain Lion, bits and updates
I am writing this post via Mountainlands dictation feature apparently this feature works quite well
(Mountainlands = Mountain Lion)
"I'm trying to use punctuation, feature in the month of life"
(Month of life = Mountain Lion)
Apparently, the only thing dictation doesn't understand in my accent is the name of the OS :)
App development is progressing well. Debugging and testing in my iPhone is really simple, as long as you've got the right XCode version/ iOS etc.
Registration of devices and the whole certification process takes a little effort, but also works seamlessly.
The next step would be recording some narrations, and then (Try) and publish the app.
I've opened up a page for the app on facebook - Come say hi.
Saturday, July 21, 2012
Testing the water with a new iOS app.
A couple of weeks ago, I was looking for a fun educational app for my kids.
I've found out that all related apps aren't free, and most are crap. Real crap.
Deciding that something which I can easily implement should not cost, I've started to fiddle with it, and built a simple web prototype in a couple of hours.
When it was nearly ready, I loaded the page on my phone, and gave it to my girl to fiddle with.
Looks like she liked it, I tested it with a couple of my friend's children, and decided to make it an app.
As it's a very simple idea, I've decided to keep it simple, with an entry screen for parents to brag in Facebook that their kids are playing with my app, and also decided to use phonegap (Just so that I'd be able to easily create an Android version, if I wanted to).
Phonegap installation and integration with xcode is very simple, and it also has a cute Facebook native extension, using either the native app, or the web interface for approving posts. (Though for iOS6 it won't be necessary, as Apple would have its Facebook integrated inside its SDK)
The next step was enrolling to Apple's iOS dev program.
Due to the fact that I live in Israel, and not registering myself as an american company, I have to fax (!!!) a purchase form to Apple, along with credit card info. I know, this seems ridiculous.
A lame start, but I'm determined to have my first app published!
I will post more soon, after I begin the app approval process with Apple.
I've found out that all related apps aren't free, and most are crap. Real crap.
Deciding that something which I can easily implement should not cost, I've started to fiddle with it, and built a simple web prototype in a couple of hours.
When it was nearly ready, I loaded the page on my phone, and gave it to my girl to fiddle with.
Looks like she liked it, I tested it with a couple of my friend's children, and decided to make it an app.
As it's a very simple idea, I've decided to keep it simple, with an entry screen for parents to brag in Facebook that their kids are playing with my app, and also decided to use phonegap (Just so that I'd be able to easily create an Android version, if I wanted to).
Phonegap installation and integration with xcode is very simple, and it also has a cute Facebook native extension, using either the native app, or the web interface for approving posts. (Though for iOS6 it won't be necessary, as Apple would have its Facebook integrated inside its SDK)
The next step was enrolling to Apple's iOS dev program.
Due to the fact that I live in Israel, and not registering myself as an american company, I have to fax (!!!) a purchase form to Apple, along with credit card info. I know, this seems ridiculous.
A lame start, but I'm determined to have my first app published!
I will post more soon, after I begin the app approval process with Apple.
Wednesday, July 11, 2012
Reading time #3
Once again, some nice reference stuff to read and enjoy.
First, a must read for every dev manager/ architect: I bet you over-engineered your startup - Try and read the comments as well - There's one I really like about backbone.js.
Here's something nice: An app for bullying reports. I think municipalities and local police departments should implement such apps, to see 'hot spots' of violence, and also make reporting a lot easier. A mobile phone does so many things, it's about time that it would help the community keep themselves safe.
My friend Moshe Kaplan from dSero with a nice article about SEO in Amazon AWS news.
Some new frameworks and tips:
- KineticJS makes 2d drawing easy, and is also pretty fast.
- A wonderful tutorial for creating clouds with css3. Opens your mind for lots and lots more ideas (Try use faces instead of clouds...)
Another useful UX related article: Overhauling a UI without upsetting the users (Thanks Itai:)).
And finally, a thought: The big tech companies have learned from the pharma industry: Since anyone can develop everything right now, and manufacturing is easy, intellectual property is the only way to make sure you have control over the market.
And unlike the pharma industry, you don't need to be a scientist, and spend years of FDA approval to get your product out there. Microsoft are buying patents from AOL, Apple is suing everyone, Samsung counter sues, and seems like the big techs' legal budget is going to be bigger than their R&D.
This is going to kill the small and medium businesses in the industry, unless legislation will somehow be able to protect them. Otherwise, we might as well give up our jobs, or relocate to China, where copyright rules are... More flexible :))
First, a must read for every dev manager/ architect: I bet you over-engineered your startup - Try and read the comments as well - There's one I really like about backbone.js.
Here's something nice: An app for bullying reports. I think municipalities and local police departments should implement such apps, to see 'hot spots' of violence, and also make reporting a lot easier. A mobile phone does so many things, it's about time that it would help the community keep themselves safe.
My friend Moshe Kaplan from dSero with a nice article about SEO in Amazon AWS news.
Some new frameworks and tips:
- KineticJS makes 2d drawing easy, and is also pretty fast.
- A wonderful tutorial for creating clouds with css3. Opens your mind for lots and lots more ideas (Try use faces instead of clouds...)
Another useful UX related article: Overhauling a UI without upsetting the users (Thanks Itai:)).
And finally, a thought: The big tech companies have learned from the pharma industry: Since anyone can develop everything right now, and manufacturing is easy, intellectual property is the only way to make sure you have control over the market.
And unlike the pharma industry, you don't need to be a scientist, and spend years of FDA approval to get your product out there. Microsoft are buying patents from AOL, Apple is suing everyone, Samsung counter sues, and seems like the big techs' legal budget is going to be bigger than their R&D.
This is going to kill the small and medium businesses in the industry, unless legislation will somehow be able to protect them. Otherwise, we might as well give up our jobs, or relocate to China, where copyright rules are... More flexible :))
Saturday, June 30, 2012
Don't fall in love with frameworks
The javascript world is on fire!
You've got tens of frameworks, all made to enable making javascript and web development easy.
angular, backbone, less, _, GWT, wicket, the old and established extjs, prototype, yui, and jquery (To name a few) have become common names among developers.
Some frameworks are meant to make your life easier with dom traversing and manipulation and encapsulate javascript features (jQuery, prototype), some add UI functionality (extjs, yui), while others offer full application frameworks.
However, these frameworks come with a price.
Once you bind your application to a framework, it's very hard to get rid of it. It's very hard to change parts of your application, once your web application is fitted with the paradigm of a framework.
Binding UI to model is another problem - Some of these frameworks bind data to UI components.
While this makes your initial development easy, once your application surpasses some volume and features, programmers tend to break this model (Something which is quite easy with javascript).
Binding is also very hard to debug - Sometimes you'll get an impossible to understand and follow call stack, especially with frameworks which bind model to UI components via events.
Another reason is performance: If all you want is a 3 page application which loads json objects, parses them and presents them on screen, using a full fledged MVP framework is a little bit of an overhead.
... And now, for the worst part.
You've written a nice widget/ control/ viewer/ whatever.
Now someone wants that object in his legacy system.
It's very hard to integrate binded code.
You tell him you can't.
He asks you why did you use the framework, if your code isn't recyclable.
You say 'it is, but you need to rewrite your whole client'.
CTO approaches you with angry eyes.
The rest - You know.
So next time you consider using a flashy, 'easy' to use framework, please ask yourself these questions:
- Will you need to reuse this code somewhere else?
- How much overhead will the framework add? Is it really necessary?
- How intrusive is that framework, in case you want to replace it?
- How much time would it take your team to develop the features you need from the framework? Don't add a full fledged framework for the sake of a neat button!
- How cryptic is the code? (Angular.js is a good example - Great framework, but you need to go all the way with it in order for you to enjoy its advantages.)
- How easy is it to debug? I know some of them are really, really hard.
And, finally:
In 6 months from now, will it bring value to your system, or will you need a month of knowledge transfer just to get someone new to write features into your app.
Be responsible - Use new technology that brings value, not heartbreak...
You've got tens of frameworks, all made to enable making javascript and web development easy.
angular, backbone, less, _, GWT, wicket, the old and established extjs, prototype, yui, and jquery (To name a few) have become common names among developers.
Some frameworks are meant to make your life easier with dom traversing and manipulation and encapsulate javascript features (jQuery, prototype), some add UI functionality (extjs, yui), while others offer full application frameworks.
However, these frameworks come with a price.
Once you bind your application to a framework, it's very hard to get rid of it. It's very hard to change parts of your application, once your web application is fitted with the paradigm of a framework.
Binding UI to model is another problem - Some of these frameworks bind data to UI components.
While this makes your initial development easy, once your application surpasses some volume and features, programmers tend to break this model (Something which is quite easy with javascript).
Binding is also very hard to debug - Sometimes you'll get an impossible to understand and follow call stack, especially with frameworks which bind model to UI components via events.
Another reason is performance: If all you want is a 3 page application which loads json objects, parses them and presents them on screen, using a full fledged MVP framework is a little bit of an overhead.
... And now, for the worst part.
You've written a nice widget/ control/ viewer/ whatever.
Now someone wants that object in his legacy system.
It's very hard to integrate binded code.
You tell him you can't.
He asks you why did you use the framework, if your code isn't recyclable.
You say 'it is, but you need to rewrite your whole client'.
CTO approaches you with angry eyes.
The rest - You know.
So next time you consider using a flashy, 'easy' to use framework, please ask yourself these questions:
- Will you need to reuse this code somewhere else?
- How much overhead will the framework add? Is it really necessary?
- How intrusive is that framework, in case you want to replace it?
- How much time would it take your team to develop the features you need from the framework? Don't add a full fledged framework for the sake of a neat button!
- How cryptic is the code? (Angular.js is a good example - Great framework, but you need to go all the way with it in order for you to enjoy its advantages.)
- How easy is it to debug? I know some of them are really, really hard.
And, finally:
In 6 months from now, will it bring value to your system, or will you need a month of knowledge transfer just to get someone new to write features into your app.
Be responsible - Use new technology that brings value, not heartbreak...
Tuesday, June 19, 2012
Want to get rich by creating a killer app?
Well, you most likely won't.
There aren't many companies making direct money from selling app in either iOS or android devices.
Let's do the math.
Suppose your app costs a buck per user.
Now suppose your app has a million paid downloads.
This means 1000000$ in revenues.
An average app would cost you 100000$ to make. (Most cost more, some less)
Now take out Apple's 30%, your of making the app and taxes, and all that's left is ~300000$.
While no small change, this isn't exactly retirement money.
However, if you could sell your app to 1 million users, you're probably doing something right - and get the attention of some big companies, or easily fund your next app.
Still not convinced? Let's do some simple math then.
Apple has given app developers (Up to now), ~4 billion dollars in revenue share. Divide that by 4 years since the store exists, and assuming that the cost of a developer is 100K$ per year, this means that in average, 10000 people (A year) are making their living from this revenue.
The others are losing their (Or other people's) money.
But now let's think of a different strategy:
Make it free, and earn from... well... um...
Not everyone could make lots of money from apps. Actually, except for high end games or the occasional hit, no one does. Most companies have app driven services and value, which generate revenue - That's a more probable model.
So the next time you've got a brilliant idea for an app and want to consult the techie that would invest 6 months of work for 50% shares, think what you're really offering him, and don't be offended if he politely says 'no'.
;-)
There aren't many companies making direct money from selling app in either iOS or android devices.
Let's do the math.
Suppose your app costs a buck per user.
Now suppose your app has a million paid downloads.
This means 1000000$ in revenues.
An average app would cost you 100000$ to make. (Most cost more, some less)
Now take out Apple's 30%, your of making the app and taxes, and all that's left is ~300000$.
While no small change, this isn't exactly retirement money.
However, if you could sell your app to 1 million users, you're probably doing something right - and get the attention of some big companies, or easily fund your next app.
Still not convinced? Let's do some simple math then.
Apple has given app developers (Up to now), ~4 billion dollars in revenue share. Divide that by 4 years since the store exists, and assuming that the cost of a developer is 100K$ per year, this means that in average, 10000 people (A year) are making their living from this revenue.
The others are losing their (Or other people's) money.
But now let's think of a different strategy:
Make it free, and earn from... well... um...
Not everyone could make lots of money from apps. Actually, except for high end games or the occasional hit, no one does. Most companies have app driven services and value, which generate revenue - That's a more probable model.
So the next time you've got a brilliant idea for an app and want to consult the techie that would invest 6 months of work for 50% shares, think what you're really offering him, and don't be offended if he politely says 'no'.
;-)
Tuesday, June 12, 2012
The importance of hackathons
Hackathons have become common practice of many companies.
15 years ago while working for verint, we were three programmers from different disciplines that convinced our managers to let us take 3 days each quater to tackle a bug/ system problem/ feature which needed a boost. We would then dedicate these days (And nights) to come up with a working solution or prototype, which sometimes changed the way the company works, solved a major problem for one of our customers, or just accelerated a process (Like performance analysis or enhancements) which could not be done in the normal lifecycle.
Such practices are even more important in large companies. Developers in companies which have a slow, long waterfall type (Even if daily work is agile) processes tend to become more 'typewriters' than 'code warriors' (Or ninjas :)).
A hackathon brings back the joy of coding and creation to such people.
A successful hackathon not only does that, but also shows the rest of the organization what you can accomplish in short bursts and by cutting red tape. Projects that were estimated as months were finished in days. This shakes up your organization, and sometimes makes a good reality check for the way organizations work.
I'd like to finish with some basic recommendations for hackathons:
- Set the goal before beginning. Make sure it is presentable later. (Working demo would be best, even if all you're doing is performance enhancements)
- Remove all of the mondain tasks from the team - This is crucial.
- No processes. If someone is managing the hackathon, the only meetings allowed are brainstorming.
- If applicable, add a product/ UX member to the team. For example, a GUI person can provide you with insights which would give your result much more impact.
- Make the team diverse as possible, but make sure the team is composed of people who can work together. This is not about bonding.
- Start coding as fast as you can.
- Make sure your result is shown to as many people as you can.
- Don't promise anything in advance, but try to reward the team after a successful demo.
Don't bury your best coders in documentation and meetings. Good coders love to code. Let them.
15 years ago while working for verint, we were three programmers from different disciplines that convinced our managers to let us take 3 days each quater to tackle a bug/ system problem/ feature which needed a boost. We would then dedicate these days (And nights) to come up with a working solution or prototype, which sometimes changed the way the company works, solved a major problem for one of our customers, or just accelerated a process (Like performance analysis or enhancements) which could not be done in the normal lifecycle.
Such practices are even more important in large companies. Developers in companies which have a slow, long waterfall type (Even if daily work is agile) processes tend to become more 'typewriters' than 'code warriors' (Or ninjas :)).
A hackathon brings back the joy of coding and creation to such people.
A successful hackathon not only does that, but also shows the rest of the organization what you can accomplish in short bursts and by cutting red tape. Projects that were estimated as months were finished in days. This shakes up your organization, and sometimes makes a good reality check for the way organizations work.
I'd like to finish with some basic recommendations for hackathons:
- Set the goal before beginning. Make sure it is presentable later. (Working demo would be best, even if all you're doing is performance enhancements)
- Remove all of the mondain tasks from the team - This is crucial.
- No processes. If someone is managing the hackathon, the only meetings allowed are brainstorming.
- If applicable, add a product/ UX member to the team. For example, a GUI person can provide you with insights which would give your result much more impact.
- Make the team diverse as possible, but make sure the team is composed of people who can work together. This is not about bonding.
- Start coding as fast as you can.
- Make sure your result is shown to as many people as you can.
- Don't promise anything in advance, but try to reward the team after a successful demo.
Don't bury your best coders in documentation and meetings. Good coders love to code. Let them.
Monday, May 14, 2012
Reading time #2!
It's time for some more links to inspirational stuff...
This 2009 article at wired is one of my favorites. It talks about how 'good enough' easily beats 'great' in so many aspects. Whenever approaching a big design or architectural task, I tend to go back to this article a little bit. People tend to over design stuff, and try to come out with a Lamborghini (That costs like one to develop, sell and maintain), when all their customers want is a Mazda...
If you're always looking for 'the next thing' in dev technology and new stacks, you have to visit the changelog regularly. Lots of emerging technologies, useful libraries and code - All the goodies us geeks need.
For all you non-coders out there, here's a great article on starting a tech company without coding knowledge, and, this great article by @martingryner shows the other side of entrepreneurs recruiting a tech co-founder.
The new iPad paves the way for laptops, PCs and tablets with astronomical resolutions. As resolution gets higher, sites with dynamic adaptation to screen resolution need to scale differently. A simple reflow is not enough - Reflow your site, and your font size will be too small to read. Scale your site, and graphics quality degrades. This article gives some pointers about redesigning your website for retina displays.
And, finally, here's an article comparing between the two leading cross platform mobile development SDKs - Phonegap vs. Titanium. If you're considering cross platform app development, you should read this one.
This 2009 article at wired is one of my favorites. It talks about how 'good enough' easily beats 'great' in so many aspects. Whenever approaching a big design or architectural task, I tend to go back to this article a little bit. People tend to over design stuff, and try to come out with a Lamborghini (That costs like one to develop, sell and maintain), when all their customers want is a Mazda...
If you're always looking for 'the next thing' in dev technology and new stacks, you have to visit the changelog regularly. Lots of emerging technologies, useful libraries and code - All the goodies us geeks need.
For all you non-coders out there, here's a great article on starting a tech company without coding knowledge, and, this great article by @martingryner shows the other side of entrepreneurs recruiting a tech co-founder.
The new iPad paves the way for laptops, PCs and tablets with astronomical resolutions. As resolution gets higher, sites with dynamic adaptation to screen resolution need to scale differently. A simple reflow is not enough - Reflow your site, and your font size will be too small to read. Scale your site, and graphics quality degrades. This article gives some pointers about redesigning your website for retina displays.
And, finally, here's an article comparing between the two leading cross platform mobile development SDKs - Phonegap vs. Titanium. If you're considering cross platform app development, you should read this one.
Thursday, May 3, 2012
Hacking your product...
During every company's life cycle, there comes a time where you have to think about strategy.
Where do you want to see your company a year from now? Five years?
The same applies to your product. Though product vision inherits deeply from the company's vision and strategy, sometimes the best ideas could come from the product itself. An accelerator for these ideas could come by approaching your own product like a kid approaches a box filled with Lego pieces.
Try tearing apart your product into its essential components. Find a feature piece, and see what you can do with it.
This is how Amazon kicked off their AWS product...
Where do you want to see your company a year from now? Five years?
The same applies to your product. Though product vision inherits deeply from the company's vision and strategy, sometimes the best ideas could come from the product itself. An accelerator for these ideas could come by approaching your own product like a kid approaches a box filled with Lego pieces.
Try tearing apart your product into its essential components. Find a feature piece, and see what you can do with it.
This is how Amazon kicked off their AWS product...
Sunday, April 8, 2012
Simple Gallery - The next phase
Been thinking a lot about my Simple Gallery Management Project.
So far, it's been downloaded ~200 times (130 for version 2.0), and after implementing ~6 projects with it, I'm thinking about taking it to the next step, and making it an even simpler, more generic CMS.
This means generalizing the database, redoing the management portal into a cool, hierarchy-like content portal.
I'll still be using HTML/ JS/ PHP (For json API)/ MySQL as a platform, simply because the cheapest hosting services are under that platform. I could implement it with node.js and mongodb, but that would be overkill. Only when I implement a simple social network, then I might use these platforms - There are few services (Like dotcloud) which do node.js and mongodb hosting, and they are not meant for the SOHO customer requiring our services (myartichoke).
This also got me thinking - What about social networks? Does anyone really need to implement a social network anymore? The 2 major risers in the social network battlefield these days (instagram and pinterest) are less about social, and more about sharing and following, rather than full fledged social networks. This means that these social networks have the 'core' social features (contacts, feed, responses and likes) built into them, but not much more - Facebook and Google+ have a whole envelope of features which try to integrate the web into their sites.
Of course, all these networks also have RESTful web services, allowing for third party developers to integrate into their network as well. This has also become a common practice.
I've also considered multi tag support, but came to realize that I'm using this feature as a 'category' (news/ objects/ shows etc.) when implementing sites - That is why I'll probably change 'tags' to 'categories', and maybe add multi tag support later.
In scope as well is making the GUI a little more '2d' and consistent. Adding an integrated toolbar per item (Like twitter's), maybe convince my wife to design some buttons for me :))
I'll update soon, once the new version begins to show signs of life.
So far, it's been downloaded ~200 times (130 for version 2.0), and after implementing ~6 projects with it, I'm thinking about taking it to the next step, and making it an even simpler, more generic CMS.
This means generalizing the database, redoing the management portal into a cool, hierarchy-like content portal.
I'll still be using HTML/ JS/ PHP (For json API)/ MySQL as a platform, simply because the cheapest hosting services are under that platform. I could implement it with node.js and mongodb, but that would be overkill. Only when I implement a simple social network, then I might use these platforms - There are few services (Like dotcloud) which do node.js and mongodb hosting, and they are not meant for the SOHO customer requiring our services (myartichoke).
This also got me thinking - What about social networks? Does anyone really need to implement a social network anymore? The 2 major risers in the social network battlefield these days (instagram and pinterest) are less about social, and more about sharing and following, rather than full fledged social networks. This means that these social networks have the 'core' social features (contacts, feed, responses and likes) built into them, but not much more - Facebook and Google+ have a whole envelope of features which try to integrate the web into their sites.
Of course, all these networks also have RESTful web services, allowing for third party developers to integrate into their network as well. This has also become a common practice.
I've also considered multi tag support, but came to realize that I'm using this feature as a 'category' (news/ objects/ shows etc.) when implementing sites - That is why I'll probably change 'tags' to 'categories', and maybe add multi tag support later.
In scope as well is making the GUI a little more '2d' and consistent. Adding an integrated toolbar per item (Like twitter's), maybe convince my wife to design some buttons for me :))
I'll update soon, once the new version begins to show signs of life.
Monday, March 5, 2012
Big data, small code
Building a big data driven web application used to be a big thing. Relational databases, links tables, complicated queries and stored procedures...
Java containers, cache management, state - Big architecture, costing a lot of money, setup and development time.
Scaling also used to be a big thing. Databases needed to scale. Web servers needed to be synchronized. Whenever state or caching was applied, data integrity was a big, big issue.
With new servers like node.js and databases like mongodb, the web stack just got a whole lot simpler.
No need for complicated tables, queries.
IO is faster, without the need for object translations from tables to xmls to jsons or whatever.
And - More important - Indexing, multiple indexing and complex queries are supported as well.
Programming is also much, much simpler. Using dynamic language like javascript is much simpler than using Java. The whole setup is simple - Actually, these servers are extending javascript to be a native language, rather than living inside the browser sandbox. That way, your whole web application is written in one language.
Connectivity modules with other services (amazon, azure, mysql etc.) are available, and expanding rapidly.
My suggestion - Give it a shot in your next web application. If you like javascript like I do, this might be the smartest move you've done.
Edit: (Thanks to @lightpriest for pointing that out): Like all software solutions, you also need to make sure that this solution serves your problem better than 'old' web stack solutions. Read the other side here.
Java containers, cache management, state - Big architecture, costing a lot of money, setup and development time.
Scaling also used to be a big thing. Databases needed to scale. Web servers needed to be synchronized. Whenever state or caching was applied, data integrity was a big, big issue.
With new servers like node.js and databases like mongodb, the web stack just got a whole lot simpler.
No need for complicated tables, queries.
IO is faster, without the need for object translations from tables to xmls to jsons or whatever.
And - More important - Indexing, multiple indexing and complex queries are supported as well.
Programming is also much, much simpler. Using dynamic language like javascript is much simpler than using Java. The whole setup is simple - Actually, these servers are extending javascript to be a native language, rather than living inside the browser sandbox. That way, your whole web application is written in one language.
Connectivity modules with other services (amazon, azure, mysql etc.) are available, and expanding rapidly.
My suggestion - Give it a shot in your next web application. If you like javascript like I do, this might be the smartest move you've done.
Edit: (Thanks to @lightpriest for pointing that out): Like all software solutions, you also need to make sure that this solution serves your problem better than 'old' web stack solutions. Read the other side here.
Thursday, February 23, 2012
Reading time!
Part of my work week is dedicated to reading and learning.
Most of my reading these days is actually UI/ GUI related stuff, as we're closing a large project at work, and are going through some final GUI iterations.
The 'Little Big Details' blog is dedicated to small but neat and significant UI features found over the web/ mobile world.
This blog, of presentation expert Jan Schultink (Idea Transplant) contains all sorts of tips and notes about presentations, presentation design etc.
Wired's webmonkey has some neat notes in their UI/ UX section.
Here's a neat book by Google about web design.
Terry Martin's great blog got some great insights about design, tech and startups.
And, finally, some management stuff:
My company's COO is a big believer in Theory Of Constraints, and has started to implement this project management methodology in our company (Time To Know).
Basically, TOC works by identifying the project chain and building blocks, trying to deal with each building block as fast as you can (Which also means using as many resources in parallel on each building block to speed up the task), and daily reviews to find the critical (Longest) chain, and speed it up.
This method, though counter intuitive sometimes, has been implemented in the project I'm leading, with wonderful result. My team (~20 UI/ GUI/ Developers/ Testers) have sped up our project delivery times, management overhead is lower, and we're actually enjoying the process...
If you're managing a medium to large size project, my suggestion would be to give it a try. Though it takes some commitment, it seems to be working well for me... As well as reduce original cost in ~30%.
A link to our TOC consultancy company would be added to this post soon.
Most of my reading these days is actually UI/ GUI related stuff, as we're closing a large project at work, and are going through some final GUI iterations.
The 'Little Big Details' blog is dedicated to small but neat and significant UI features found over the web/ mobile world.
This blog, of presentation expert Jan Schultink (Idea Transplant) contains all sorts of tips and notes about presentations, presentation design etc.
Wired's webmonkey has some neat notes in their UI/ UX section.
Here's a neat book by Google about web design.
Terry Martin's great blog got some great insights about design, tech and startups.
And, finally, some management stuff:
My company's COO is a big believer in Theory Of Constraints, and has started to implement this project management methodology in our company (Time To Know).
Basically, TOC works by identifying the project chain and building blocks, trying to deal with each building block as fast as you can (Which also means using as many resources in parallel on each building block to speed up the task), and daily reviews to find the critical (Longest) chain, and speed it up.
This method, though counter intuitive sometimes, has been implemented in the project I'm leading, with wonderful result. My team (~20 UI/ GUI/ Developers/ Testers) have sped up our project delivery times, management overhead is lower, and we're actually enjoying the process...
If you're managing a medium to large size project, my suggestion would be to give it a try. Though it takes some commitment, it seems to be working well for me... As well as reduce original cost in ~30%.
A link to our TOC consultancy company would be added to this post soon.
Monday, January 2, 2012
The New System Dilemma
...Or, how to roll out a new system and stay alive.
When rewriting a system/ subsystem, there's never a way to satisfy all your customers.
Usually, the organization expects you to rewrite everything to work exactly the way it worked before, with better performance and completely revamped UI/ GUI, at a fraction of the original system cost. Not to mention all the new features.
This sound absurd doesn't it? Well it doesn't. This is exactly what you've told them when asking for their approval to rewrite the whole thing.
So you're in a rough spot now.
You are expected to deliver the new system soon, the whole project is in a delay and not too stable anyway, and the organization still considers the old system, which is stable, mature and field proven (Though it costs a lot to maintain), as its best solution - Urgent market needs call for more personal to work on the current system, and your team is at risk to be 'vandalized' for those proposes.
In my 15 years of working in high tech, I've experienced many millions of dollars burn over such projects. Ambitious complete rewrites, sometimes trying to squeeze hundreds of work years in (Usually) tenth or less of the time.
It's always the same story: Take your best managers and engineers out of the daily cycle, isolate them and expect miracles to happen. Wait one, two years, and when the whole thing collapses, go into salvage mode, and try to incorporate as many components as you can in your products.
Sometimes the whole system goes to waste... Along with your best managers and engineers.
So what can you do to turn the tables?
Your first target should be 'setting your foot at the door'. This means deciding on your first customer, and focusing on the specific needs and goals of that one specific. Don't try to implement the whole organization's needs at once - Focus on your first rollout. This way you'll be able to roll out in baby steps, rather than go out with a bang... You'll also be able to minimize your risks, and gain the time to stabilize your new system. Set expectations with your first customer, let them know exactly what they're getting, and more important - what they're not getting. Which features they will miss, and why.
Your second target should be getting your organization's cooperation with the rollout. Some of those people might not have been involved with your 'incubator' project. Some of them might even think that the current system is much better. How do you get them to be on your side? Start involving them with the final decision making and scoping. Get their engagement by exposing all the cards in your deck. Partner with them, because you won't make it without them. This might even mean brushing up on your political skills...
Once your first, even if minor, rollout is successful, and the organization is on your side, you'll have enough breathing room to actually finish your project, and moving it on to the regular maintenance cycle.
When rewriting a system/ subsystem, there's never a way to satisfy all your customers.
Usually, the organization expects you to rewrite everything to work exactly the way it worked before, with better performance and completely revamped UI/ GUI, at a fraction of the original system cost. Not to mention all the new features.
This sound absurd doesn't it? Well it doesn't. This is exactly what you've told them when asking for their approval to rewrite the whole thing.
So you're in a rough spot now.
You are expected to deliver the new system soon, the whole project is in a delay and not too stable anyway, and the organization still considers the old system, which is stable, mature and field proven (Though it costs a lot to maintain), as its best solution - Urgent market needs call for more personal to work on the current system, and your team is at risk to be 'vandalized' for those proposes.
In my 15 years of working in high tech, I've experienced many millions of dollars burn over such projects. Ambitious complete rewrites, sometimes trying to squeeze hundreds of work years in (Usually) tenth or less of the time.
It's always the same story: Take your best managers and engineers out of the daily cycle, isolate them and expect miracles to happen. Wait one, two years, and when the whole thing collapses, go into salvage mode, and try to incorporate as many components as you can in your products.
Sometimes the whole system goes to waste... Along with your best managers and engineers.
So what can you do to turn the tables?
Your first target should be 'setting your foot at the door'. This means deciding on your first customer, and focusing on the specific needs and goals of that one specific. Don't try to implement the whole organization's needs at once - Focus on your first rollout. This way you'll be able to roll out in baby steps, rather than go out with a bang... You'll also be able to minimize your risks, and gain the time to stabilize your new system. Set expectations with your first customer, let them know exactly what they're getting, and more important - what they're not getting. Which features they will miss, and why.
Your second target should be getting your organization's cooperation with the rollout. Some of those people might not have been involved with your 'incubator' project. Some of them might even think that the current system is much better. How do you get them to be on your side? Start involving them with the final decision making and scoping. Get their engagement by exposing all the cards in your deck. Partner with them, because you won't make it without them. This might even mean brushing up on your political skills...
Once your first, even if minor, rollout is successful, and the organization is on your side, you'll have enough breathing room to actually finish your project, and moving it on to the regular maintenance cycle.
Subscribe to:
Posts (Atom)