Wednesday, 13 July 2011

How software companies die

Source: http://fuzz-box.blogspot.com/2011/05/how-software-companies-die.html


How software companies die
An essay by Orson Scott Card, found it lurking in my articles folder but i lack the source.
A very true and entertaining read. Hope you enjoy it.

The environment that nutures creative programmers kills management and marketing types - and vice versa. Programming is the Great Game. It consumes you, body and soul. When you're caught up in it, nothing else matters. When you emerge into daylight, you might well discover that you're a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. But you don't care, because your program runs, and the code is fast and clever and tight. You won. You're aware that some people think you're a nerd. So what? They're not players. They've never jousted with Windows or gone hand to hand with DOS. To them C++ is a decent grade, almost a B - not a language. They barely exist. Like soldiers or artists, you don't care about the opinions of civilians. You're building something intricate and fine. They'll never understand it.

BEEKEEPING
Here's the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. You can't exactly communicate with them, but you can get them to swarm in one place and when they're not looking, you can carry off the honey. You keep these bees from stinging by paying them money. More money than they know what to do with. But that's less than you might think. You see, all these programmers keep hearing their parents' voices in their heads saying "When are you going to join the real world?" All you have to pay them is enough money that they can answer (also in their heads) "Geez, Dad, I'm making more than you." On average, this is cheap. And you get them to stay in the hive by giving them other coders to swarm with. The only person whose praise matters is another programmer. Less-talented programmers will idolize them; evenly matched ones will challenge and goad one another; and if you want to get a good swarm, you make sure that you have at least one certified genius coder that they can all look up to, even if he glances at other people's code only long enough to sneer at it. He's a Player, thinks the junior programmer. He looked at my code. That is enough. If a software company provides such a hive, the coders will give up sleep, love, health, and clean laundry, while the company keeps the bulk of the money.

OUT OF CONTROL
Here's the problem that ends up killing company after company. All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Either he cashes out, or he brings in management types who end up driving him out, or he changes and becomes a management type himself. One way or another, marketers get control. But...control of what? Instead of finding assembly lines of productive workers, they quickly discover that their product is produced by utterly unpredictable, uncooperative, disobedient, and worst of all, unattractive people who resist all attempts at management. Put them on a time clock, dress them in suits, and they become sullen and start sabotaging the product. Worst of all, you can sense that they are making fun of you with every word they say.

SMOKED OUT
The shock is greater for the coder, though. He suddenly finds that alien creatures control his life. Meetings, Schedules, Reports. And now someone demands that he PLAN all his programming and then stick to the plan, never improving, never tweaking, and never, never touching some other team's code. The lousy young programmer who once worshiped him is now his tyrannical boss, a position he got because he played golf with some sphincter in a suit. The hive has been ruined. The best coders leave. And the marketers, comfortable now because they're surrounded by power neckties and they have things under control, are baffled that each new iteration of their software loses market share as the code bloats and the bugs proliferate. Got to get some better packaging. Yeah, that's it.

Persistently Bad Startup Ideas

Source: http://www.quora.com/What-are-some-startup-ideas-that-persistently-fail?srid=hsN

  1. Social Shopping - Learnt this the hard way, (May be ahead of it's time).
  2. Rivals to Google - DDG and Bing seem to be doing a decent job though.
  3. Foursquare for something - Foursquare is a great service but checkins do not work in every space unlike many think.
  4. Most Messaging Apps - Facebook and SMS are taking this space over and startups trying to replicate BBM just miss the main points.
  5. Any App/Site which just adds some Social Feature expecting to push them ahead of the competition. We are not the same as everyone we have on Facebook.
  6. Social Browsers - Look at Rockmelt, their iPhone effort is shameful and Flock is Dead, RIP.
  7. Facebook Rival - People watch the Social Network and think it's that easy to kill facebook just by "telling their friends about it".
  8. YouTube Rivals - Unless they hit a niche (A la Vimeo) they have no use as YT offers up to 4k resolution, 3D video, partnerships and lots of content.

iPhone App generators - there're enough of them and they all produce default apps that suck.

Q&A-Portals - because there're enough of them and it takes very long to make them good. And there's Stakcexchange and Quora.

ToDo-Lists - because either they're too simple to fit in people's workflow or too complex to be usable and it involves creating apps on all different platforms

Anything that involves syncing or developing for every platform - cause syncing is hard and developing for different platforms is nothing that a small startup can handle

  • Anything that makes programming "easy for non-programmers or businesspeople"
  • Micropayments
  • T-Shirts (except Threadless (and Busted Tees ... thanks Adam Kazwell))
  • Recommendations based on what your friends like
  • RSS readers
  • Find nearby people to meet/date through your mobile phone
  • Anything involving paying people to look at ads
  • Sites that purport to measure someone's trustworthiness as a standalone service, separate from any other context or functionality
  • Customized personalized newspapers focusing on mainstream news
  • Craigslist killers - but not sites that attack individual categories on Craigslist (see diagram in this question's summary)
  • To-do lists - there are tons of these, but everyone's workflow tends to be so personalized and specific to that person that none of them really catch on
  • Most blogs that are started with the intent of being businesses
  • Business that let consumers scan some kind of code, number or barcode in real life, with some special device, or lately their phone, and they get sent a URL, ad or coupon in return

Sunday, 10 July 2011

Innovation

http://www.npr.org/blogs/krulwich/2011/07/06/137621529/thinking-thoughts-the-others-haven-t-thunk

"Here's to the crazy ones, the misfits, the rebels, the troublemakers, the round pegs in the square holes... the ones who see things differently -- they're not fond of rules... You can quote them, disagree with them, glorify or vilify them, but the only thing you can't do is ignore them because they change things... they push the human race forward, and while some may see them as the crazy ones, we see genius, because the ones who are crazy enough to think that they can change the world, are the ones who do."

Don't just break the mold - shatter it to pieces.

Wednesday, 20 April 2011

Applications of Operational Amplifiers


Name: Applications of Operational Amplifiers
Status: complete
Affiliation: 18-220 Electronic Devices and Analog Circuits Lab 6
Group members: Frank
Start: 3/17/2011
End: 3/17/2011

Description:
In this lab we used multiple op amps to perform some sort of useful function.

Peak Detector
This circuit's purpose is to indicate when an input's amplitude exceeds a certain threshold.

Analog to Digital Converter
ADCs are commonly used to convert analog signals to digital signals. Examples include storage, signal processing, and display. We built a flash ADC.





Feeding different input signals into the ADC.


Ramp Generator (Oscillator)
Ramp generators are used to generate a periodic, linearly increasing signal.

Friday, 11 March 2011

Mixing Music 2

This time with GarageBand:



I've also begun playing around with PureData but it's not quite what I expected for signal processing. More on that as it develops...

In terms of inspiration, I really like what Shinsadong Tiger has made, especially for Prepix. I can't seem to find much of his stuff floating around on youtube since it's always intertwined with Beast videos, but here's my favorite:

QuickFuse Voice Application

Over spring break 2011, I built a few voice apps using QuickFuse (quickfuseapps.com), which is a web app that allows easy creation of interactive voice response applications through drag-and-drop modules. None of the apps I made are fully functional as they were rapidly prototyped. Below are the descriptions of what I made:

Hands Free Messenger
Allows you to text, tweet, and email through speech. I ran into some difficulties, especially with the email module since you have to specify a carrier and thus either have to use a single carrier (I just used gmail) or ask the user for a carrier and then branch depending on what they answered.

Meet N Eat
Look for nearby dining locations, broadcast where you are going, and see if other people in the area are going to the same spot.

Meet N Eat modules

Nearest Neighbor
Allows users to list their current locations as they're driving, and find out which other drivers are nearby that have also listed themselves as available. Aimed for the social aspect that seems to be incredibly popular in apps these days, but I abandoned this after I realized the potential for stalker abuse was too high.

QuickFuse Summary
QuickFuse is a really convenient web application for designing IVR (interactive voice response) apps, and it's cool to see how their backend processes voice pretty well. However, while testing my app I ran into the philosophy of voice apps - how they might be more convenient than what we have now?

Pros:
-After the initial dial, does not require further physical interaction.

Cons:
-Talking to a machine isn't the same as talking to a person.
-The speech recognition is far from perfect - accents, homonyms, numbers all have some issues. Numbers were especially annoying because they cannot be clumped and have to be said in a specific, digit-ized way.

Check out http://quickfuseapps.com/ if you're interested in playing around with this. They give you free call quota on sign up.

Operational Amplifiers


Name: Operational Amplifiers
Status: complete
Affiliation: 18-220 Electronic Devices and Analog Circuits Lab 5
Group members: Frank
Start: 2/24/2011
End: 2/24/2011

Description:
In this lab we messed around with various op amp circuits and analyzed the non-ideal behavior that is exhibited. We used the LM741 which has the pinout below:


We experimented on the inverting opamp and summing amplifier. Two limitations that we examined were the non-ideality of zero differential voltage input, as well as the output voltage limitations. Below are some oscilloscope pictures that show what happened when we increased the input voltage until saturation begins to occur:






Thursday, 10 February 2011

CMOS Inverter Layout

Name: CMOS Inverter Layout
Status: complete
Affiliation: 18-220 Electronic Devices and Analog Circuits Lab 3
Group members: Frank
Start: 2/9/2011
End: 2/9/2011

Description: Using L-Edit (layout editor), designed a minimal CMOS inverter using n-channel and p-channel transistors. The transistor depiction of an inverter is as follows:
We were given the constraints of λ = .5 uM, Z_n = 20 uM = 40 λ, and Z_p = 60 uM = 120 λ. In both channels, L = 2 (minimum possible L) because there were no additional constraints on it.

Lessons Learned:
-introduction to layout design in L-Edit
-minimal design rules
-using DRC to check whether or not I pass minimal design rules
-taking layout cross sections
-testing separate components helps identify which part of your layout is wrong - this applies to EVERYTHING, including unit testing, classes, modules, etc.

yes, that's a big X through our entire design...

designed whole layout in one shot, then used the DRC tool. frustration ensued.


finalized inverter layout

Saturday, 5 February 2011

Mixing Music 1

First few songs made using Virtual DJ.


In this song, I tried to line up the two beats. Resulted somewhat nicely in a "canon" but not really.

Random effects

Had a flanger on the whole time. Interesting sound. Also tried using beat patterns but still need to find out more about how they're generated. Another effect I wanted to try is dubstep, so I need to find the files for that.

Overall, I'm thinking about using the Virtual DJ software to slap together songs (there's only a limit of two tracks though it seems...) and Audacity for fixing up the signals.
Another software that I need to look into is Acoustica Mixcraft, which supports multiple tracks but for me has a steep learning curve.

Tuesday, 1 February 2011

Something Cool 1

I've decided to also post interesting videos, pictures, whatever. These will have titles "Something Cool N".

Today's subject is a cool trick for seeing infrared light.

Infrared is a type of electromagnetic radiation. It is invisible to the naked eye because it has a longer wavelength than visible light, so it is outside of our range. It is commonly depicted as thermal radiation, such as those airport machines that check your body temperature to make sure it's not abnormally high. Although our eyes aren't capable of seeing infrared light on their own, cameras are able to detect it thanks to their infrared filters.



Oooo purple.

Monday, 31 January 2011

Parity Coding

Name: Parity Coding
Status: complete
Affiliation: 18-240 Structure and Design of Digital Systems Lab 1
Group members: Arlene
Start: 1/23/2011
End: 1/27/2011

Description: Implements parity coding, which is a safety caution that adds one bit to a code word. This extra bit allows error detection when any one bit in the code word is corrupted. In an even parity code, the parity bit is set so there is an even number of 1 bits in the code word, while in an odd parity code, the opposite occurs. An interesting fact to note is that the odd parity bit can be computed as the negation of the even parity bits. The primary limitation with parity coding is that it can be assumed to be correct IFF single-bit errors are the only possible sources of corruption.

Notable issues with parity coding:
-Does not tell you how many errors
-Does not tell you where the errors are
-Can miss errors if they are of the correct parity

What I learned:
-introduction to System Verilog
-parity coding
-assigning logic inputs and outputs to pins on the hardware (xilinx spartan 3)


Asserts 1 when code word is inconsistent. In the video, I increment the input from 0 to 63.






Monday, 17 January 2011

Sign Language to Braille Glove ( --> Simon Says)

Name: Sign Language to Braille (--> Simon Says)
Status: somewhat complete
Affiliation: Build18 (build18.org)
Group members: Justin, Kee Young
Start: 1/10/2011
End: 1/14/2011

Description: The glove began with the intention of converting sign language to braille by taking gestures as inputs and returning braille as output using an LED array. The LED array currently acts as a proof of concept because making a mechanical device that can output real braille is a substantial project in its own right.
However, we ran into some problems:
1. Didn't think about how many analog inputs we needed. Unfortunately, Arduino Duemilanove only has 6, so we weren't able to attach all of the flex sensors and an accelerometer. Unfortunately, we weren't able to get our hands on a multiplexer. Should probably consider investing in a Mega.
2. LED array didn't have the pins we wanted, as well as an outdated data sheet. We weren't 100% sure how to use it without blowing it up so we decided to use wire six individual LEDs instead and control them separately.

The lack of analog inputs prevented us from using all of our sensors, which meant we wouldn't have very accurate gesture recognition. As a result, at 8pm the day before build18 demos, we decided to rewrite our software. We kept the same hardware for the most part (removed two flex sensors, removed accelerometer).
In the end, our final product was a simon says game where a number of LEDs are lit and you have to gesture how many are lit. The sequence gets increasingly longer as you get more sequences correct.

What I learned:
1. Be prepared when ordering parts under strict timelines. Have foresight.
2. Be wary of how many digital/analog I/Os you have and how many you actually need.
3. Have backup plans for when you don't have foresight.
TBA: circuit diagram, parts list, cost, code









Speaker

Name: [A Single] Speaker
Status: Complete
Affiliation: self
Start: Summer 2010
End: Fall 2010

Description: Basic circuitry for a single speaker. Based off of sparkfun's tutorial
TBA: circuit diagram




Sunday, 16 January 2011

Simple Light Switch

Name: Simple Light Switch
Status: Complete
Affiliation: self
Start: Summer 2010
End: Summer 2010

Description: Basic circuitry for a light switch
TBA: circuit diagram