Archive

Archive for June, 2009

Can you still be a single platform developer?

June 27, 2009 Leave a comment

When I joined my current company two years ago, I joined specifically as a Winforms developer. At that time the company had seperate Winforms, Web and Service teams within the development department. Within a year this had changed into one cross functional team working on various projects, so I am now exposed to more web programming (ASP.NET 2.0/3.5)  than I expected.

This is definitely a good thing and although I have struggled with some of the challenges of working with a stateless model I am getting to grips with writing the code and getting my ideas out there. I feel a more rounded developer and a more useful team member.

But I was thinking today about if people are still ‘web only’ or ‘winforms’ only developers I think even as little as two years ago that may have been the case. Now I am not sure that you can afford to be. Or if you are, you’re much better off on the web side of the fence. That said, I can never imagine telling a current or prospective employer that I would not be willing to work on a technology even in good times.

I suspect the answer is, and this is from no scientific reasoning and a few Stella’s, that while you still can be a single platform developer, you probably shouldn’t be. The Pragmatic Programmer tells us to learn a new language every year, with the amount of new technology that comes from Microsoft every year perhaps you may just need to learn a new platform.

definitely

Categories: Development Tags: ,

Listen to your onsite customer

June 22, 2009 2 comments

Recently we have been rolling out a project at work which has been in the planning stages and worked on for about 6-8 months off and on. Once the main development had started we made sure that we had regular updates with the main stakeholder. This involved a meeting once a week to show our progress discuss what they liked and didn’t like and which changes they would like to make.

The project is now ready for deployment and we are meeting a lot of resistance from the business. Our main customer seemed pleased with the product and was happy as the iterations when by, however the actual end users seem much less pleased.

I heard recently that if you don’t succeed, make sure you learn from your failure, I assume that some sort of middle ground will eventually be found and that the project will be delivered, but there are a couple of things that I will be taking away from this project.

  1. Make sure that the drops of your code are seen by as many people as possible, especially the people who will be working with the project every day
  2. Early design and mock-ups to let customers know the planned UI are very useful, I have heard good things about Balsamiq for putting together mock designs quickly
  3. Make sure you are prepared to listen to what the customer wants from the very start, rather than letting the design be dictated by the technology

Much of the work I do is with services and apps without a UI so I don’t need to worry about the human interaction, the next time I do I will be ensuring that I and my team will not be making the same mistakes again

Categories: agile Tags: