A great development manager once said, "It's just software." That simple statement tells a much larger story. Software development for most companies is all about time and money. Most requests can be satisfied but developers have a tendency to rebut with "no" when they believe the work is too difficult, requires extensive time, or for a variety of other concerns.
When I first heard about unit testing using a framework like JUnit, I thought it was such a simple and powerful concept.
If you ever need to persuade management why it might be better to deploy a larger change in multiple stages and push it to customers gradually, read on.
This article is the third part of the Cloud Delivery Blueprints series. It discusses how to go from no cloud infrastructure and no continuous integration set up to having a functioning Deployment Pipeline in Amazon Web Services. It discusses high level topics while also providing a reference implementation so it’s easy to follow along with
By applying a faulty implementation of the well-known Quicksort algorithm, we show how to find bugs faster. The method is based on reducing the input so that the smaller input still trigger the fault while even smaller doesn't.
In this post I want to go over Law of Demeter (LoD). I find this topic an extremely important for having the code clean, well-designed and maintainable.
I’ve been playing with the language a bit while tinkering with the Java 8 support under development by the Eclipse Java development tools (JDT) project.
I would recommend this book to system administrators and customers using Microsoft Dynamics AX 2012. Also it is a good investment for a technical consultant working with an AX partner.
I have created a small project to demonstrate some features of Ansible, the new DevOps hotness, including Vagrant VMs for running Ansible and for testing the configuration. Either go straight to
I will admit I have been a strong opponent of those listing roles and organizations as DevOps. Primarily because DevOps is a way to do something and creating a role DevOps Engineer is just putting lipstick on the pig for those looking to hire a Linux Sysadmin or infrastructure script coder. Likewise, the DevOps organization is a somewhat more likeable term, but still ambiguous at best.
It is hard to imagine life before self-service in grocery stores. For developers and young startups growing up with cloud solutions like Amazon Web Services, Heroku and Engine Yard, self-service is already becoming the norm. Some of these folks probably cannot even imagine a world before this.
This is part of a series of micro-blogs (somewhere between a tweet and a full on blog) on Clean Code. In this post, I’m going to focus on one big culprit in obfuscated, not clear clean code — Conditionals (i.e. if statements). Let’s look at an example:
One of the asides I made in “Programmers without TDD will be unemployable” which caused a bit of outrage in the testing community was my comment “Manual testing is a sin.” While I have been unfair to many testers, and somewhat simplistic, I still stand by the statement. Let me expand on why I still stand by the comment and why I am wrong.
Test-Driven Development with Mockito provides a general introduction to test-driven development (TDD) before looking at application of Mockito to implement test doubles as part of test-driven development.
When going for test-driven development, we all know that the unit test code becomes critical part of the code base. Is because of this that it is really important to have a solid unit test source code structure; flexible, intuitive and maintainable enough so that when the amount of unit tests grow, it does not become an uncontrollable mess.
It's not clear, actually, if this involves a TCP/IP "Mystery". What it may involve is a simple lack of ability to communicate. Or something.
Our skills and customs as programmers always tend to leak into our lives. If you haven't realized, you are probably trying to do everything an agile way. Aren't you? In this article, see one of these leaks in action: duplicating the bug.
The suspect’s DNA had been found at 40 crime scenes, linking her to burglaries, narcotics and six murders. It turns out the infamous ‘phantom’ wasn’t a murderer at all. Police were hunting an innocent factory worker who fatefully handled the same cotton swabs used to collect DNA samples from the crime scenes.
My preference is to simply remove the private modifier and make the method package private. Why is this a good idea? I will get to that after I discus the problems with the other methods.
The client sees the website in a different way, and if there is a problem, they will describe it to you with the words they know. Every developer has spent time talking or chatting or exchanging emails with a client who wants work done, but can't explain what they need in a way the developer can understand.
Sometimes you have to extend or maintain a legacy codebase that usually contains few cohesive classes. There often isn't time in this hectic agile world to make such classes easy to unit test the standard way. When you are trying to unit test such classes, you often realize that unusual mocking is needed.
The last couple of months I have met several young developers that either looking for the first job or are still trying to get their bachelor degree. Many of them asked me to give them my advice on how they can make their first steps in the software development career. In this post I summarize my advice to all these “young” and ambitious developers. Don’t be fooled by the word young.
The idea that the way to increase Agility is to reduce the number of disciplines and replace everything with a super developer who can manage the team, work with the business, write great code, test it and then manage its deployment and support, is a pipe dream
In business there are many ways to gain a better perspective about a project Customer visits are a fantastic way to expose developers to actual and/or potential clients. Initiating a visit shows customers a personal level of attention that they rarely get from most companies they interact with.
Code review is a great software instrument and you should definitely use it to improve the quality of your code. But like any other tool, it may be misused sometimes. That’s why I came up with a list of best practices to guide you when reviewing your peers’ code.