Manda QoP

Setting up a continuous delivery process can be quite a momentous task, especially when retrofitting to an existing product, however, I'm quite lucky with a current project in that we're at the very start of the project so there are no existing processes in place. Once you've read this, I'd love feedback on my solution and ideas for improvements if you have any. When I joined the project the developers had already put continuous integration and deployment processes into place using Team Foundation Server (TFS) and Octopus. So the challenge placed before me was to extend this process out to a full continuous delivery plan complete with testing, reporting, full end to end life cycle overview, and of course, happy project, change and release managers. This is taking a bit of thinking.  I can easily do the geek thing and get down into the nitty gritty of setting all of this up but the business needs to see how it works at a higher level, and they also need to be give

I've just started to use Java, having never coded with it before, and today ran into a bit of trouble with date comparisons.  The obvious option that I wanted to use had been deprecated so I needed to find an alternate. Whilst Google and StackOverflow are normally my very best friends when it comes to this sort of issue, today they were only a little helpful, pointing me in roughly the right direction but not actually hitting the target. What I needed to do was add 6 years to a variable date and then compare that to today's date.  Sounds easy enough, and in Java version 6 it was, but now things have changed.   I found a useful class called Calendar, however, all the online blogs, tutorials and user comments only showed me how to add years to today's date, which is easy as pie.  What none of them told me was how to add 6 years to another date.   It's probably really obvious for most folks out there, but given the number of questions I found by people asking how to

It is a black art trying to get the costs right on a development estimate. Too much money and the client will go elsewhere, even if your quote is realistic and reasonable. Too little and you become one of the suppliers the client goes to when the realistic estimate sounds too high. If you're one of the second estimate types, the sort who say it will cost less than it actually will, then you run the risk of not completing the work on time and within budget, you will have stressed out staff and may end up costing your company money instead of making money. So what to do about this? Personally I aim for realistic where possible and include a contingency amount as well just in case of blowouts. I also do a very detailed breakdown in the estimate so the client knows why this project of theirs will take 2000 man hours. So a client has approached you and asks "how much to build this? Just give me a rough estimate of dollar amount and time". You have very little detail, perhaps f