I'm going to have to watch that announcement I guess, because I couldn't make heads or tails of that memo.
Wait, where is he saying that? He's only tweeting a bunch of stuff about world cup predictions.
@LarryLarsen: Ha, I used one of those things on the left back in the early nineties. Even though I kept wanting to spin around more than 180 degrees and got tangled up in the cables that hung from the back of the helmet, the experience totally blew me away.
I was ten years old though, so...
Good advice guys!
CaRDiaK: it is a fun place to work. The whole small startup thing is fun, and we're working on unusual and interesting stuff. Your point about project management is spot on: we're trying some things but are having difficulty finding something that really works. I'll definitely take a look at that book, Code Complete is still a favorite of mine so I'm interested in what he has to say on this subject.
MasterPi: I guess the guy who is part manager/part designer/part developer owns all the project and does the sort of things you mention. However, he is also the guys who asked me to come up with a process that'll work better for us. :P
Michael Butler: I'll take a look at your suggestion too. I currently see it used on Amazon for $4 so that won't hurt.
Harlock123new: I like the idea that many simultaneous projects are unavoidable for now and as such we should plan for that. That should at least go some way towards more accurate time estimates...
TexasToast: there are no bigger companies than us in this field. We have a few competitors that compete on price but we are able to provide better applications and expertise. So far, anyway...
davewill: I'll mention the need to unit test core stuff. I like that idea. My biggest fear when it comes to unit testing is having to constantly rewrite the tests for our viewmodels because the requirements change sometimes on a weekly basis. I'm not sold on the code reviews myself, but we do have the situation where one guy may fall ill or go on holiday and then "his" project goes haywire and the other two have to spend a lot of time figuring out that guy's code. I guess I figured code reviews could help prevent that, as well as improve the quality of the code we all write when there's always someone else watching too, but I'm starting to feel like it would soon become a chore and either suck up time or fall by the wayside. There are no real communication issues, but things are so busy that everybody usually just dives in to their own project/area (there's a "web guy", a "XAML guy", a "multitouch guy", a "Unity3D guy", etc) and the others never see or hear about the code, either because it's not their field of expertise or because they already have so little time to spare for their own stuff.
spivonious: we looked into scrumm but didn't feel like it would fit: we can't meet (either in person or via skype) with our clients as often as scumm requires, for instance. We've picked up a few small things from a scrumm course, though: we're succesfully using a Definition of Done and have a daily standup with the entire company (five people who each have three minutes to get the rest up to speed on what they are doing), which helps.
I work for a small, independent software development startup. We've been in business for nearly three years now and things are going pretty well. We've got a pretty steady stream of projects for an ever expanding client base, and as a result have carefully started hiring new staff and temporary help. We're now at five permanent members of staff, of which two are full-time developers and one divides his time between development, design, and managing the business.
Because the workload has been getting higher, we've run into some problems: we're making long hours, are missing deadlines, are unable to give accurate estimates regarding when a project will be completed, and the quality of our code is dropping. I've been asked to come up with a development process that better fits our company and projects.
We usually work on several projects at once – this is inevitable duet to the amount of projects we've taken on and the small number of developers we have. We currently more or less divide this up in two week intervals: work on project A for two weeks, work on project B for two weeks, and then inevitably some problem with project A or C will pop up and we'll spend a day intended for project B on project A and C.
Our clients are from all over the country and from various backgrounds. Some are talkative, some are not. Some expect weekly updates, some have no problems with not hearing from us for two months. We prefer to work in small iterations: get a prototype out the door and into the client's hands as fast as possible (usually about a month after development started) and then iterate on that every two to four weeks. We've found that this is essential for the kind of projects we do and the fact that our clients often have no real idea what they want until they've had something approaching what they want in their hands for a while.
Right now, our development process is pretty straight forward, but obviously lacking. Our designer comes up with an idea for an application and a rudimentary graphic design, and our developers (one, two, or all three) sort of divide the work on an ad hoc basis and start building. Every now and then, we check where we are, and adjust if necessary. There's not much more to it than that.
I've been thinking of doing code reviews: every piece of code is checked at by at least one developer who didn't write it. This seems like a good way to start improving the quality of our code, but it takes a lot of time that we just don't have. The same goes for unit testing: we've spent weeks writing tests and often found ourselves constantly having to tweak the tests because we found out they weren't testing the right things, or weren't testing enough. That project took significantly longer than projects where we didn't unit tests and just squashed bugs when we found them. Also we didn't have anything to show the client for weeks. Possibly we were just doing it wrong, of course.
I've also been thinking of adding a dedicated tester to our team: someone who finds, categorizes and reports bugs to us, so the developers have to spend less time finding bugs and playing support for our clients, and have more time to spend on actually fixing bugs and developing the application. Obviously this is a significant investment for a small team like ours, but I have a suspicion that it's a more effective way to spend money than just throwing more developers at a project.
As to providing better estimates, I have no real idea. We've dabbled in planning poker, but in my experience that amounted to little more than the wildly inaccurate guesswork we were already doing. Finally, I want to formalize the design process more, to a certain extent. Obviously due to the iterative development we can't really set any design in stone, but it probably wouldn't hurt if we spent some more time up front formalizing both the application architecture and the graphical design.
Basically, I have a reasonable idea of what we can improve and what we're currently lacking, but I have no real concrete ideas about how we can achieve this goal. Anyone here who struggled with the same problems? How did you overcome them, or what traps did you fall into that you'd suggest we avoid?
What I didn't like about that was the underlying assumption that people will build a WP app. At least Android on WP means existing devs wouldn't have to do much (maybe?) and things will just work. WP on Android still requires app houses to invest time in WP, which they don't want to do given the marketshare problem.
No, because they won't be making a WP app: they'll be making an Android apps, so all they have to care about is Android's marketshare. The incentive to do it via this method is that they'll be using native .NET/XAML. People pay Xamarin huge amounts of money for that convenience.
The fact that this will also result in a Windows Phone app (possibly even a superior one) for no cost at all is an added bonus. And Microsoft will automatically see a Windows Phone version for each Android app developed this way.
People want to develop for Android, but they also want to use .NET. If you give them that in a way that -also- closes the WP app gap, you win.
I'm wondering if it shouldn't be the other way around: Windows Phone apps on Android. That way if you want to build an app for Android you can just build it in .NET without paying huge amounts of money to Xamarin, and as an added bonus all those apps will also be immediately available for Windows Phone.