If you are building software, you need requirements. They are input for implementation and test and they can serve as means of acceptation. Requirements can be as explicit, implicit, formal or informal as long as it works in your particular situation.
That said, if you have requirements, they must make sense. I often see the ‘too many requirements syndrome’ in projects. Most often caused by someone that obviously had too much time on her hands. Continue reading
After a successful proof of concept for our one click deploy framework, we are now planning for the first production implementation. Here is a quick impression of how this is going to look:
In our series about the interns working at Avisi, we feature Maik Diepenbroek today. Maik is rearchitecting parts of the NXP Temptation application with a focus on testability, code quality and maintainability. Continue reading
In our series about the interns currently working at Avisi the spotlight now turns to Danny Cobussen. Danny is working on a concept we call ‘one click deploy‘. One click deploy is about installing applications to a cloud environment where the cloud is not a vendor SAAS offering, but a cloud environment that is fully under the clients control. Continue reading
Once upon a time when software was delivered to a customer the final phase in the project was acceptance. Today the iterative approach in agile software development incorporates acceptance as a recurring reality. This limits surprises afterwards, but does it guarantee project success? Continue reading
This is the next post in our series about the interns that currently work at Avisi. This time we introduce Mats Stijlaart. The Atlassian plugin framework is used on several projects to enable seamless extensions. Mats’s assignment is all about finding an alternative for, or confirm the choice of, the Atlassian plugin framework.
Some people oppose to the idea of using gitflow because it conflicts with what Martin Fowler says:
“In practice it’s often useful if developers commit more frequently than that. The more frequently you commit, the less places you have to look for conflict errors, and the more rapidly you fix conflicts.”
No matter how much fun we have in building software, software is hardly ever built for fun. Customers have a need for something, a requirement to fulfill, a use case for it. And they are paying to get it done.
In software development, it’s pretty normal to stage your deliverables from your Development environment to Test to Acceptation en finally to Production (DTAP). On it’s way to production your software meets different data sets, hopefully improving in quality and relevancy. Continue reading
I love complicated architectures, architectures that involve numerous components, failover constructions and what not. But sometimes simple architectures draw my attention and amaze me because of their straightforward and refreshing simplicity. Let’s take load balancing as an example: Continue reading