So you have an idea for some software, some spare cash, but you can’t program. “I know!” you think. “I will just pay someone to write me an app! What could go wrong???”. Well, lots. And there are a few things that you should look for when paying someone to build your great idea or next business differentiator that may help ensure that you end up with at least some chance of a good outcome.
There has been a few good articles written about how we should or should not build software like we build houses. But for me, these articles were not really addressing the main point. Sure, I get that we build houses more like the typical Waterfall methodology in software, and that Waterfall has it’s haters (in my opinion for good reason). And I get that Agile is considered awesome way better amazing for building software (if a little super zealotry verging on religious). But if I knew nothing about building software or building houses, my money would be much safer and the outcome much more predictable if spent on building a house than software.
Quite often when you are developing software you need to take a dependency on other software solutions, and more and more often this dependency takes the form of a web service. This creates problems when you want to start testing your software at greater than a unit test level granularity, as you often have to provide a piece of software to masquerade as the service that you are coupled to if you want consistent and reliable tests.
A side effect of having a very complex build environment is the need to provide people with some ability to impact assess the result of particular build jobs being triggered. At my current client we use NuGet packages and internal NuGet feeds for all our binary dependency management, and TeamCity for all our build jobs, so it seemed that all the information that we needed to provide this impact assessment was already available.
Due to the complexity in the codebase and development processes at a current client of mine, I have had to extend NuGet in some interesting ways recently. This has resulted in an open source command line extension set called NuGet.Extensions (snappy name, huh?) and an additional library that NuGet.Extensions depends on called NuGet.Extras (on fire with these names) that deal with some of these complexities.
Quick little trick: If you want to host your code on your Mac, and share it via VMWare shared folders, and you want to be able to compile it, and you are getting errors like this currently:
I have had the opportunity to spend some time attempting to unravel work on an application recently that has been written to take extensive advantage of extension methods (no pun intended). With the introduction of extension methods Microsoft handed developers a very powerful tool, but one that is very easy to abuse.
I generally end up working in large organisations where the software you deal with is an accretion of good and bad ideas implemented in a haphazard fashion and held together with spit and string. Much of the complexity within these environments comes down to configuring all these disparate pieces of technology to communicate with each other correctly, and there seems to be a standard set of approaches you find people using to manage the complexity of this configuration.
One of the things that I struggled most with when starting to code using MonoTouch was unit testing and mocking. There was little in the way of information as to how this should be done, and there was even less help in the software patterns encoded into the platform as default by our Apple overlords. Although the MVC pattern is fine as far as it goes, when you are talking such a mixed bag of technology that is MonoTouch/iPhone development, it comes with its problems.
So a while ago I decided not to write another blog post whilst I was in the employ of my previous corporate overlord. This was in part due to the fact that, if I blogged based on what I saw there, I would have simply been reinventing an already tried and true but ultimately career limiting formula. Well, I am out from under that particular (and particularly evil) corporate heel now, and figured it was about time to put some thoughts down on keyboard.
Last week I released a piece of software that some might find useful. RenderConfig provides a simple way to manage application configuration, although it comes into its own in complex enterprise applications that have multiple environments/servers/locations.
As I weave my way through the slow moving sidewalk of iPod-drone witches hats, I am forced to hope that I am in time to get a good seat. Your thinking public transport, right? Cause we have all been there….sweaty strangers with prominent, head-height armpits and the joys of lining up for fictional timetables. But nope. We are talking work.
So I am working alongside a Waterfall type software project, in an environment where (fr)agile projects have been seen in the wild, and someone is mentioned as being the “Alliteration Manager”. Or at least, thats what I think they said. I mean, on an Agile project (even a (fr)agile project) I would probably have heard it as “An Iteration Manager“*. Context is everything, after all. And you just don’t have Iteration Managers with Waterfall, right?
There are a lot of people out there solving problems with computers these days. We might not have quite reached the infinite monkeys tipping point (substitute Shakespeare for a social networking website, without the option of cultural longevity) but we must be getting close. At the very least, based on some of the developers I have met, we are hiring a lot more monkeys these days.
(fr)Agile* Development, or Fragile for short, is the art of convincing management that you are doing Agile development, whilst ignoring most of the primary tenets of the art.
You probably aren’t reading this on my website (although RSS seems to be working still) as my hosting company has decided to advertise on my website without letting me know up front! Hopefully something that I can get fixed quickly…
One of the things that comes up often in build management is the management of external libraries or dependencies. There are a lot of ways to deal with this, and they are usually language dependent (Java rocks in this regard via Maven, whilst there doesn’t appear to be anything equivalent in the Microsoft world).
Build management is one of those tasks in a project team that most project managers are not particularly aware of. Many developers do not identify this as a separate task either, it is just something that the better developers do as part of their job, and the worse ones ignore.