Jeremy SeitzWith InterVenture we are able to extend our in-house team optimally. Due to the agile organisation and direct communication, our team in Belgrade is completely involved in all major projects.
Clean coding is one of the programming elephant paths of today. “Clean code always looks like it was written by someone who cares.” – says Michael Feathers. It asks for new practices and specific discipline. As a result it brings back the results.
In time, we have recognized value of clean code.
In .NET world MSBuild is the build engine, the guy that transforms your code to binaries. Code is built by interpreting scripts and they hold a sequence of build steps. Usually, the only scripts that are used are project files, like csproj or vbproj files. On build server,
Writing code is a beautiful experience. Every programmer will surely testify it is. Writing software is a different thing, though. It is a job, and it comes with things not so attractive. First of all, it comes with customer requirements. Then it comes with schedules and deadlines. It is also known of constant change,
Yes, developers are strange. Let’s just face it. Developers operate on a different wavelength than managers. Agile developers in particular tend to deliver in short cycles, listen for the client feedback and turn that into the next development cycle.
At the same time, management wants to know dates and costs.
In our company, we are trying to regulate the development in slightly indirect ways. We have recognized that direct management of developers is a bad idea. Quite the contrary, we have recognized that nourishing a well-informed product owner brings benefits that cannot be achieved otherwise.
Product owner is responsible to join the three poles of the structure: clients,
Writing software is amazingly simple when it comes to processes. Don’t let the complexity of the software itself sneak into the process of producing code. Understanding and modeling the domain, testing and packaging, all of those are one side of the coin. Managing the process is the other side.
Developers in my company (and most senior developers in general) are power users. Power users often need to access functionality of OS that is not available in GUI (or meant to be). On the other hand, they want to automate repetitive tasks.
This is the place where consoles step in.
Having a team which is separated geographically carries several challenges, one of them being the question of planning sprints. Root problem here is that members holding different roles are stationed in distant offices.
One of the most important lines of division appears between business analysts and development staff.