The fastest way to build new software is not to rush. It's to build quality. If you're working on bugs, you are not working on features.
Don't build bugs. Be thoughtful. Design properly. Test. Automate.
Monday, December 31, 2012
Tuesday, February 12, 2008
Must Read: A Software Design Manifesto
An absolutely must read for anybody in software development, from newbie junior programmers to seasoned software designers, is A Software Design Manifesto by Mitchell Kapor.
The essay is almost 20 years old, and it still holds true today.
The essay is almost 20 years old, and it still holds true today.
Tuesday, January 22, 2008
Roadmaps and Features and Enhancements
The 37 Signals blog about how you don't need a product roadmap spawned a great discussion in my company. We all sorta kinda all agreed that while having a published roadmap is dangerous, we do need to communicate a product "vision" to our customers. The function of aggregating and analyzing all the features that go into a roadmap is also still necessary for product planning stages. Especially the features that clients have submitted themselves.
I personally argued that having a running list of client submitted features not only tells you what your clients want in the software, but you could also possibly glean patterns of how they use the software simply by analyzing what they've requested.
I don't feel that way anymore, and here is why.
I've had the most mind-numbing task lately. I've had to review a list of approx. 200 feature requests for the product planning phase of our next release. As I'm reviewing each and every complaint...I mean feature request, I realized something. None of these are real feature requests. Sure, technically, renaming a button from Submit to Save or adding a column onto a report are feature requests. But those are more like product improvements then real features.
I attended a webinar from KnowledgeInfusion the other day, and Jason Averbrook said something that really crystallized what we really need from our customers. I'm paraphrasing here, but the message essentially was that the real winners in enterprise software development are not the ones who automate existing business processes, but are the ones who revolutionize existing business processes.
That got me thinking. Feature requests that clients submit essentially try to improve the product so their existing business processes run smoother. They don't tend to submit requests to change their business process because the people who have permissions to log in and submit a request are so focused on the project (i.e. go-live), it forces them to think short sightedly. I have yet to really come across a feature request that says "Look, we've been doing this like that for so long, and it ain't working. What we really would like to see is.......".
So I want to stop reviewing the list of "features" now. But I can't because, you know, management would kick my ass. But I have to admit I truly believe I'm wasting my time here. This is what you get when you don't work for a company driven by research. If your company depends on your customers telling you what next to build, you're probably an enterprise software company that does not employ thought leaders in that space (which is actually OK if its run properly). However if you have industry leaders who simply know the space inside and out, I'd wager that relying on them to drive your product forward is just as good as asking your clients.
thoughts?
I personally argued that having a running list of client submitted features not only tells you what your clients want in the software, but you could also possibly glean patterns of how they use the software simply by analyzing what they've requested.
I don't feel that way anymore, and here is why.
I've had the most mind-numbing task lately. I've had to review a list of approx. 200 feature requests for the product planning phase of our next release. As I'm reviewing each and every complaint...I mean feature request, I realized something. None of these are real feature requests. Sure, technically, renaming a button from Submit to Save or adding a column onto a report are feature requests. But those are more like product improvements then real features.
I attended a webinar from KnowledgeInfusion the other day, and Jason Averbrook said something that really crystallized what we really need from our customers. I'm paraphrasing here, but the message essentially was that the real winners in enterprise software development are not the ones who automate existing business processes, but are the ones who revolutionize existing business processes.
That got me thinking. Feature requests that clients submit essentially try to improve the product so their existing business processes run smoother. They don't tend to submit requests to change their business process because the people who have permissions to log in and submit a request are so focused on the project (i.e. go-live), it forces them to think short sightedly. I have yet to really come across a feature request that says "Look, we've been doing this like that for so long, and it ain't working. What we really would like to see is.......".
So I want to stop reviewing the list of "features" now. But I can't because, you know, management would kick my ass. But I have to admit I truly believe I'm wasting my time here. This is what you get when you don't work for a company driven by research. If your company depends on your customers telling you what next to build, you're probably an enterprise software company that does not employ thought leaders in that space (which is actually OK if its run properly). However if you have industry leaders who simply know the space inside and out, I'd wager that relying on them to drive your product forward is just as good as asking your clients.
thoughts?
Wednesday, January 9, 2008
Wanted: Software that helps you make money
Can enterprise software help companies actually make money?
Most enterprise software is designed to automate business processes with the hopes to drive down cost. I understand that when costs decrease, net revenue increases. However costs are finite. Can software be designed to help accelerate revenue on positive side (as opposed to decrease the negative)?
My peers and I could only think of the marketing apps that based on purchase history, user profile, or surfing history, can directly advertise things that you might be more interested in. But are there any more?
Software shops that focus on this aspect of the world have to be the wave of the future in my eyes, otherwise the software industry is doomed to remain marginalized as the cost centers of the business world.
Let me know your thoughts....
Most enterprise software is designed to automate business processes with the hopes to drive down cost. I understand that when costs decrease, net revenue increases. However costs are finite. Can software be designed to help accelerate revenue on positive side (as opposed to decrease the negative)?
My peers and I could only think of the marketing apps that based on purchase history, user profile, or surfing history, can directly advertise things that you might be more interested in. But are there any more?
Software shops that focus on this aspect of the world have to be the wave of the future in my eyes, otherwise the software industry is doomed to remain marginalized as the cost centers of the business world.
Let me know your thoughts....
Wednesday, November 28, 2007
Where's the Privacy?
I hate it when people assume that if you're online and they send you an instance message, then you have to respond.
The problem I find with IM, and many Web 2.0 software like Facebook and MySpace, is that it puts the power in the person querying for information, and not in the person providing the information. (or in the IM world, the power is in the person initiating the conversation, and not the person accepting the conversation).
This construct has fostered a culture where if you don't respond to an IM, or if you don't add a person as a friend, then that person feels that they are being ignored and you look like a jackass.
So what do I do? I want to use Facebook, but I don't want to accept every friend invitation sent to me. (And FYI folks - there is a reason why we lost touch). I also want to use MSN, but I have work to do and can't chat on every message - not to mention that damn flashing window is such a distraction.
I think I'm going to uninstall my MSN at work. The distractions are significant enough where it has affected what I was doing at the time, but I feel that it is also changing work culture to the point where people think that MSN history is some form of official documentation used for decision making - which is really scary (and lazy and full of potential errors and misinterpretations) - but that is a topic for another date.
The problem I find with IM, and many Web 2.0 software like Facebook and MySpace, is that it puts the power in the person querying for information, and not in the person providing the information. (or in the IM world, the power is in the person initiating the conversation, and not the person accepting the conversation).
This construct has fostered a culture where if you don't respond to an IM, or if you don't add a person as a friend, then that person feels that they are being ignored and you look like a jackass.
So what do I do? I want to use Facebook, but I don't want to accept every friend invitation sent to me. (And FYI folks - there is a reason why we lost touch). I also want to use MSN, but I have work to do and can't chat on every message - not to mention that damn flashing window is such a distraction.
I think I'm going to uninstall my MSN at work. The distractions are significant enough where it has affected what I was doing at the time, but I feel that it is also changing work culture to the point where people think that MSN history is some form of official documentation used for decision making - which is really scary (and lazy and full of potential errors and misinterpretations) - but that is a topic for another date.
Subscribe to:
Posts (Atom)