Download Squad has posted the first article on how to create your own game company.
From the article:
Of course, nothing beats a great idea. Unfortunately, good ideas are everywhere. What you need to do is make sure your amazing idea is developed properly.
Philipp Lenssen @ Google Blogoscoped: good programmers are lazy and dumb.
via Scoble
It amazing how often this is not done but this tip is right on the money.
When you’re building something (not just prototyping), take the extra time to lay a good foundation. If you don’t, you’ll spend waste a lot of time in the future propping things up in ugly ways.
from Alex King
Giles Turnbull documents how a simple request on the 43 Folders mailing list for a software app led to a quick solution by part time programmer Sam Devore.
Graham Glass has an excellent series on producing several software products. All of the information is based on his personal experiences and he describes how each company is founded in a way to avoid having to take on investors while still creating a viable company and product quickly.
In Part 6 of the series, the most recent entry, Graham provides a bullet list of assumptions that he works under. His list is a good framework for all developers to work off of, especially since he shares some of his results of using the list.
Nick Bradbury gives us an inside look on how he develops TopStyle and FeedDemon.
Adam Stiles follows up Nick’s post with an inside look at the NetCaptor development process.
Kevin Dangoor has a post on his blog, Blue Sky On Mars, about implementing a support system up front that will help your product become a success instead of a drain of your time. One of the points he makes, which has been said by many others, is that you should only answer a question once by making use of forums and other online systems where a customer can help themselves.
Usability specialist, John S. Rhodes, found a Slashdot entry where a developer complains about having to “dumb down” an application for the user becuase they repeatedly clicked the submit button even though there was an error each time. In his post, John asks the following:
Are users stupid or not? Do developers have the right to be angry?
After reading the Slashdot post linked by John, I found the following comment by the original poster after someone suggests to disable the submit button so that it can’t be pressed multiple times.
I like solving technical problems, but I’m not so keen on social problems like this one… human behavioral modeling isn’t my favorite subject.
In this case, I think the developer doesn’t have the right to be angry. Your thoughts?
Apress has made the book Dissecting a C# Application: Inside SharpDevelop available for free as an ebook. The book goes through the development team’s process of designing and developing SharpDevelop and provides a lot of information that may be beneficial in your own development process.
via Matt Berther by way of Christopher Hawkins
Lachlan Gemmell, who left his job and started a software company last year, has started a blog about programming with Delphi.
Microsoft employee Scott Gunnerson details the testing and bug tracking process going into ASP.Net 2.0 and Visual Web Developer. The numbers are pretty impressive. 1.4 testers per developer, 105,000 test cases and 505,000 test scenarios.
An article from the December 2003 MCP Magazine outlines the several roles that go into software development.
Jeffrey Veen reviewed several open source content management systems and came up with several suggestions to improve usability. These suggestions apply equally well to any software project. The suggestions include:
via kottke.org