IT is just IT

When I wanted to dive into and understand Microservices Architecture the following reading list was suggested to me: Life beyond Distributed Transactions:an Apostate’s Opinion by Pat Helland This paper explores and names some of the practical approaches used in the implementations of large-scale mission-critical applications in a world which rejects distributed transactions. It discusses the management of fine-grained pieces of application data which may be repartitioned over time as the application grows. It also discusses the design patterns used in sending messages between these repartitionable pieces of data. Migrating to Microservices by Adrian Cockcroft In this presentation Adrian Cockcroft discusses strategies, patterns and pathways to perform a gradual migration from monolithic applications towards cloud-based REST microservices. Idempotence Is Not a Medical Condition by Pat Helland An essential property for reliable systems. Distributed systems theory for the dis

Because my experience with regard to the deployment and configuration of a Build vNext agent along side of my on-premise TFS2015RC test configuration which was everything but an easy walk in the park, I decided to share a little write-up about what I have discovered till today because it might be of value to anybody who wants to get started with the new build architecture of Team Foundation Server 2015. In this post I describe how to deploy and configure the build agent. In the second part I intend to describe the creation and configuration of a build definition. I already have a built up and running, it is just I currently don't have the bandwidth available for the write-up. This blog post refers to the experience provided by TFS2015 RC. Be advised today my experience with the new TFS build architecture is still limited. The guidance provided is just to get you started on this subject and is not intended for use in software development production environments. Objectiv

The other day my management asked me about my view on what a software development team would look like to face the challenges imposed by the current trends like for example digital transformation, the digital customer experience, SMAC, Big Data & cloud computing, to which I like to refer to with the term “the third platform technologies” . When thinking about the engineering skills and capabilities my team would require to successfully face these challenges, I could list all existing ones and a few new ones. With this approach I would assure myself  I have the complete software engineering body of knowledge readily available in my team and this would enable the team to successfully address any challenge during the delivery of a solution. However if I would move this forward, I would eventually end up with a team of such a considerable size, I highly doubt my business sponsor would provide me the funds required to assemble such a team. Also the size of the team would also c

My experience as an Open CITS Certification Board Member The Open Group Certified IT Specialist (Open CITS) certification program — formerly ITSC — is an independent global certification program for qualifying the skills, knowledge and experience of IT specialists. Accepted and applicable worldwide, from a wide range of organizations in more than 50 countries worldwide. Capgemini’s internal Software Engineering Certification Program is an Accredited Certification Program and adheres to the Open CITS Certification Policy and Open CITS Accreditation Policy. Certified Software Engineers on levels 2 and up benefit from the accreditation, because it provides them the opportunity to attain Open CITS certification with a little extra effort. The Open CITS certificate represents an ideal mechanism for Capgemini’s Software Engineers to demonstrate knowledge, success and overall business capabilities outside Capgemini. The Open CITS program requires applicants to demonstrate skills and experienc

This list describes the reading program a software developer needs to work through to achieve full professional standing. The plan described is a generic baseline plan for a software professional who wants to focus on development. Introductory Level To move beyond "introductory" level, a developer must read the following books: Adams, James L. Conceptual Blockbusting: A Guide to Better Ideas, 4th ed. Cambridge, MA: Perseus Publishing, 2001. Bentley, Jon. Programming Pearls, 2d ed. Reading, MA: Addison-Wesley, 2000. Glass, Robert L. Facts and Fallacies of software Engineering. Boston, MA: Addison-Wesley, 2003. McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998. McConnell, Steve. Code Complete, 2d ed. Redmond, WA: Microsoft Press, 2004. Practitioner Level To achieve "intermediate" status, a programmer needs to read the following additional materials: Berczuk, Stephen P. and Brad Appleton. Software Configuration Manag

Here is a common question I get regularly. In this case it was Howard, a co-worker from the UK: “Probably a dumb question but...how do you define scope yet remain agile?  Is it woolly wording, do you define it using some kind of abstraction or do you define in terms of number of iterations? The key being that, in my experience, most people what some idea of what they're getting up front, yet in remaining agile we want to defer that sort of decision until later.” This is not at all a dumb question because it identifies the key difference between agile and traditional project delivery. Here is my response to the questions. In my projects scope is a matter of defining this at the right abstraction level, or maybe more precise defining it without much detail. First thing you need is an concrete idea about the project’s scope boundaries. You can use the business case and vision for this purpose. They should provide the constrains with respect to for example business processes to suppo