APIs have become very important in a world of interconnected applications. APIs have improved a lot in the past years, especially due to the JSON + REST standards. But there’s still a more subtle lesson to be learned about them that is a hit and miss: APIs are user interfaces too. It’s in the acronym: Application Programmable Interface. Interface for what? For other software systems. But who writes those systems? Developers. So it’s really a user interface for developers who work with your application. Since APIs are user interfaces, we should apply UX principles and techniques to make them easier to use. Here are 5 of them.

Over the past 6 months, I’ve been working with a customer who develops hardware appliances. They were facing a challenge with complaints from users about one of their products, which appeared a few months in. Needless to say, the cause of such bugs requires long and thorough investigation. The hardware appliance runs a real-time OS, which is currently in transition from a proprietary system to FreeRTOS. Most of the code is written in C, and it uses system calls for creating threads and synchronizing them. The codebase is old, since it has been running for about 10 years.

I’m a developer. We’re not well known for our communication skills; at least I know I had my problems. Most of them came from the fact that my natural tendency is to ignore emotional cues and to dwell on facts alone. In many cases, that works fine. Sometimes, though, it creates unnecessary friction and can upset people. As a consultant, mentor and coach, I had to communicate better. Practice makes perfect. I strongly advise you to do it. However, if you like to stay the way you are, but oil your interactions with non-geek entities a bit, I have a pattern for you. 

Every once in a while, I have conversations with people about what really is TDD. Since I built a certain knowledge on the topic in time not only by using it but also by explaining it to others, I decided to write this article that details my definite view on what TDD is. I hope you’ll find it useful.

Every once in a while, I have conversations with people about what really is TDD. Since I built a certain knowledge on the topic in time not only by using it but also by explaining it to others, I decided to write this article that details my definite view on what TDD is. I hope you’ll find it useful. As this may be a long article, I will write for Today Software Magazine a series of shorter articles on this matter. Here’s the first one.

My previous blog posts have shown how to create better software design and defined the idea of Usable Software Design. Usable Software Design comes from the simple observation that the developer is the user of a software design. My thesis is that using principles and practices from Usability in software design will create two important economic benefits: faster implementation time for common tasks and faster integration of new developers in an existing team. In this article, I will explore further usable software design starting from the simple idea that nobody likes to make mistakes but mistakes still happen. Since usable software design means software design that’s a delight to use by developers, something has to be done to prevent mistakes. So, how about Mistake-Proofing your software design to make it more usable?

In a previous Article for Today Software Magazine - 4 Ideas To Apply For Better Software Design, I wrote about the fact that we tend to perceive software design as userless. Whenever we talk about design in other domains than software, we discuss it from a user-centric point of view. Apple's products are renowned because they focus on the experience of a user with their device: how it feels, how it looks, how fast it responds, the sounds it makes etc.

Software design is all the rage now. It looks like every year a few more design ideas appear. First there were the GoF design patterns. Now, MVC is the way to do web applications, while ideas like: domain driven design, ports and adapters, microservices see increase interest and adoption. I learned software design by doing, with a mentor who kept giving me very useful (and sometimes annoying) feedback. This was before I knew about design patterns, SOLID principles or TDD. Therefore, my understanding of design starts from the core laws of software design. That's why, when my colleagues or I work with developers, we teach them not only design patterns and SOLID principles, but also a way to think about design. Here are 4 ideas you should consider when you make a design decision (that is, every time you write a function, class or module) to get better software design:

Every week, we, at Mozaic Works, in the product development team discover 2-3 potential bugs in the product we are developing during our code review sessions. This happens despite a very structured way of work and despite applying ATDD and Test First / TDD.
Yet developers and technical leads complain to us in the community or during coaching sessions and workshops about various aspects of code reviews. Here are some tips to make your Scrum Code Reviews more useful.

I have seen in my 15 years career as a developer, technical lead, project manager, freelancer, trainer, agile/lean/technical coach and again developer many failures of software development. I have also seen unexpected successes.  From all industries, software development seems rather unpredictable. As a client, you can ask for a feature that looks simple and should take a day or two, (eg. Add Euro support to an accounting system designed for French Francs) and it takes two months. Or you can ask for a feature that looks awfully complex, and it takes one day. What should you expect? A 10 times budget increase for the feature set that you need, or to have the software earlier than expected?

How fast could you create a software product starting from an idea? This is the purpose of this article. We will explain our concept of starting with an idea, finding the core value of the idea and then put it into the hands of users as fast as possible. In order to start one needs to have a clear idea on what would be the product. Create a simple bullet point list of the concept, the core values of the product and how it could be monetized. But then how could you understand if it is useful or not?

The natural career of a software developer is: junior programmer, senior programmer, technical lead / team leader, optionally architect and then it turns into management. There’s something paradoxical about this path: the career that started with writing code ends in not writing code at all anymore. After all, how can you keep up with all the new and shiny stuff that appears in technology each year? A new type of career has surfaced in the recent years, one that’s much more interesting. We will look in this article at people who don’t fit this profile, at those developers who still write code and can help others even if they are 40, 50 or 60 years old. Robert C. Martin. Michael Feathers. Rebecca Wirfs-Brock. How are they different? How can they keep up with changes?

Here’s a common situation nowadays: a large company learns about Agile and decides to adopt “agile processes”. The leadership team creates a transition plan that includes training, coaching and consultancy. They monitor the advance by asking: how many teams are agile? Because when we’ll be over 80%, we’re done transitioning and we’re agile. Right?

The Lean Startup movement was a revolution in the startup world, although it started from a simple observation. The standard way to create a startup was until recently “Build, Measure, Learn”:
- An entrepreneur comes up with a product vision;
-After obtaining necessary financing, he/she builds the product according to the vision the product is tested on the market;
- After obtaining necessary financing, he/she builds the product according to the vision the product is tested on the market

The starting of the year is a good moment to think at the future. How can you grow your career? How can you have a (more) stable job? How can you be more wanted in a competitive market?This article contains 10 technical skills that a programmer can learn and can help grow your profile with your colleagues and managers.

Executable specifications are a way of using automated tests with the purpose of documenting the functionalities of an application. Automated tests are more and more used in the software industry, with the purpose of validating the correct functioning of an application. The validation implies of course a dialogue with the persons who formulate the requests (business analysts, product owners, product managers and other stakeholders) and the automated tests do not relieve us from documenting the ways the application is used. For documenting the functionalities there are some solutions, the most common one being writing specification documents.

The idea of having communities of practice comes from the agile principle that proclaims the need of continuous improvement. One of the agile continuous improvement practices is the creation of communities of practice, on certain areas. A community has a purpose and is formed by a group of people who are passionate or interested in the same subject. For agile the objective of a community of practice is to share learning’s and experiences (the more different the better) of every participant.

In 2001, a group of people unpleased about the state of software development gathered in a mountain ski resort from Utah. One thing leading to another, they started discussing about the industrial methods applied at the time for managing programmers and about the so-called lightweight methods many of them used informally. The result of this meeting, as you probably know, was The Agile Manifesto.

As we were saying in the last articles about software craftsmanship, Test Driven Development is one of the practices considered to be at the core of a software craftsman. Besides the increasing numer of articles, blogs, short movies or books on this subject, Test Driven Development (TDD) continues to be a subject that generates confusion in the programmer communities. This article will try to structure and to clarify the subject and to offer support to those willing to learn more about it.

The software craftsmanship movement promotes the idea that the only way a developer can be fast is by behaving rationally during crisis periods. This way of thinking is a reaction to the behaviour of writing code that is hard to change and to understand, basically producing technical debt, in the moment when you need to deliver software during a short period of time. The way the software craftsmanship movement believes that a developer can become that fast is by practicing as often as possible, in most diverse environments, on platforms and languages as different as possible. Thus deliberate practice is very tightly related with any developer that calls themselves “aspiring software craftsman” or “software craftsman”.

We know from the experience of the industry that the techniques promoted by the Software Craftsmanship movement have the potential to increase the productivity of the development teams. Test Driven Development helps obtaining solutions with better design and more stable in a shorter period of time. Pair Programming helps eliminating the mistakes while the code is produced, fast knowledge dissemination in a team and finding simpler solutions. Continuous Integration helps solving integration issues between components fast and without stress. Continuous refactoring helps keeping the code flexibility, so that when the customers ask for unforeseen functionalities, the team can add them very fast.

Imagine the following situation: a team has developed for 6 months a great product that immediately sells. Users show their passion for the product by asking new features. If the team does not deliver the new features fast enough, their happiness will decrease. They might even switch to a competing application. The team must deliver quickly.

The Software Craftsmanship movement started in 2009, as a reaction to the idea that we can temporarily reduce the code quality to ship products faster. The promoters of the movement think exactly the opposite: to deliver products in time, even under pressure, we should improve the speed with which a programmer writes quality code. In the first case the users, customers and the company that produces software can suffer; users and customers due to the mistakes introduced in the applications (bugs), and the company due to medium term decrease of the production speed for new application versions and due to user dissatisfaction.