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. We at InterVenture have seen it help maintain long running projects with less effort and with higher confidence. We have learned to keep focus on the principles of clean code.
One of the most prominent protagonists of clean coding, and one of the authors of the Agile Manifesto, Robert C. Martin – Uncle Bob – has defined Principles of Object-Oriented Design. In his own words, these principles were divided into those that deal with class design, package cohesion and couplings between packages.
We want all programmers in our company to keep focused on these principles and to follow them with full understanding. This is not because we want all programmers to write the same way – Principles are not dogma and they do not lead in that direction – but because merely thinking about them trains the programmer’s eye to recognize code designed well.
So what have we done to help programmers keep an eye on the Principles of OOD? We have printed them on the wall. Now everyone can see them and, from time to time, ponder over them. We cannot tell whether this idea has enhanced our coding skills – we will never know. But we like to think that it will make us a bit better programmers in the end.
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, you can specify a solution or project file to build. However, it can do much, much more if you use it with custom scripts.
When starting the build, build server (TFS, TeamCity) passes a reference to your sln or csproj file to MSBuild. If you set it to pass the reference to another file, say ‘main.build’, MSBuild will try to interpret it as a build script.
This script can have multiple custom build steps. These could include validation of properties which are passed to script or setting up folders for build output before the build itself.
Regarding the build part, it can simply call another instance of MSBuild to build a solution or few of them and perhaps enforce a specific output directory. After the build script could have a step to run unit tests.
If build and tests pass, script can create a release/setup package by simply copying a set of files somewhere, by zipping them or by running a separate tool for making a setup (ClickOnce, InstallShield etc.). This can also include an obfuscation step for desktop applications.
Script can run your setup package, install your service to IIS web server and/or run scripts to setup database and actually create new environment. If needed, a set of integration tests using tools for automated testing (SoapUI) could be used to verify package as a whole.
Automated cycle from build to deployment can greatly increase confidence in your code, both yours and your client’s. Hence you could come to a point where you automatically deploy to production environment if tests pass. This way you are going towards continuous delivery, an ideal of developers and clients.
Many utility applications (testing frameworks, archiving utilities) support running through command line interface, which are great for running from MSBuild script. Also, many other functions like executing SQL script against a server, or setting up stuff on web/application server are wrapped in tasks built by community. Finally, you can build you own tasks in C# or VB.NET for really special cases.
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, which greatly undermines team’s efforts to deliver what was planned. Passion of coding gradually fades away, letting it all become more of a code smith kind of work.
When that happens, and it happens in virtually every software project, we look for ways to contain the difficulties and keep the project in track. Otherwise, code would begin to rot and team’s ability to progress further would be jeopardized.
The answer is in turning the coding practice into craftsmanship. It is not simple and it is far from easy. It takes time and endurance, it requires guidance and talent. But it requires less today than it used to ask for in the past. As in any other profession, one can become a craftsman by walking the elephant paths made by the craftsmen of the past.
We have seen structured programming, object-oriented programming, functional programming, aspect-oriented programming, and so on, all of that in a life span of a single programmer. Talking about “past” in this context may sound silly. Time is so condensed when it comes to computes. It is not a wonder that some of the great programmers of the past are actually active programmers today. All of these paradigms were invented to help professionals put their black belt on sooner rather than later.
We at InterVenture Nearshoring pay close attention to grow the culture of craftsmanship in our development teams. We see value in applying established practices, especially in the domain of programming theory. That gives our teams ability to manage code in the long run.
Writing software is difficult enough – there is no reason to make it even more difficult by following bad practices.
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. Asking the developers to estimate and then promising deliveries based on estimates fails miserably. Why is it so?
Falling Into the Trap
Mapping the management view onto development processes may lead to difficulties. And when difficulties begin to emerge, management often decides to strengthen the process control, only to make difficulties even more obvious.
And here is the rule of thumb: Asking developers for estimates and then putting those into a delivery road map is road map to disaster.
Things never happen that way, and estimates turn to be misleading. Managers then often look for rescue by turning to strict plan following mode. They micromanage every single developer’s activity, sometimes going into bizarre details. It all makes the development less efficient, causing even longer delays. This vicious circle quickly lowers the efficiency of the whole team, leading to further drop in motivation and many other undesired effects.
Agile Development Process
Through trial and error, we have learned that the development process should be simple. We all apply agile principles of software development, but the agility is sometimes compromised.
To keep the agility part alive in the agile project management process, we actually try to move managers away from developers. Managers are there to identify medium-term priorities. Prioritized tasks are then mixed with client’s feedback on previous deliveries to form the next development iteration.
From the development point of view, the world ends there. All the complexities of management processes, all the company-to-company negotiations, promises, strategic directives, they all live over the edge of the developers’ world.
Then How Does It Go With the Estimates?
When development is truly agile, its cycles are stable and regular. Very quickly, and that is in no more than two months, management can observe actual velocity of the team. By velocity, we mean the amount of features that can be delivered in a period of time, such as two or four weeks.
This measure is then used to roughly estimate how much time it would take the team to deliver certain larger feature. Negotiations with clients can then be steered by this almost trivial measure.
By putting the velocity into the equation, we are ensuring that the management will never feel the urge to directly manage developers. Consequently, efficiency of the development is constantly kept high, as well as the positive sentiment in the development team.
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, management and development. Product owner maps management’s long-running plans into short development cycles. Product owner ensures that development is paying due attention to client’s feedback and medium term priorities set by the management.
The Rule Is: No Direct Control Over Developers
Managing software development team boils down to managing relations between the product owner and the team. As long as both ends of this relation perform well, there is no need for the company managers to interfere and destabilize the development.
We believe that direct management fails in development because programmers do not have the same set of interests as managers. Programmers have deeper technical understanding of the problem. They need requirements, explanations about the product, list of priorities. The rest is programming and that is what development team does the best.
Our past experience confirms that development teams perform best when they are left alone with their goals set. The goal of the management then is to set development goals. This typically boils down to setting priorities and providing the development with the information they need.
The Other Way In the Two-Way Street
It will probably sound like a stereotype if we say that software development is a two-way street. But it definitely is a process in which both sides – those who use the software and those who write it – have to pay attention to what the other side has to say.
It is sometimes hard to explain things. Users have their own ways when it comes to doing business. Will the developers stay in the way, forcing a solution which may have technical justification but simply doesn’t fit user’s needs? Or will the programmers put an extra effort to reach a solution which is of higher value to the user?
Will the users stay stubborn and confident in their opinion even in cases where a certain level of technical knowledge would help them get a better understanding? Or will they listen to advice from programmers?
These are the situations in which product owner can mediate. He can help close the scope of each iteration so that both the developers are able to ship the solution in due time and clients are satisfied with the features they receive.
Why Not Project Manager?
From our past experience we can confidently say that development teams do not need to be managed. They need explanations of what the software is expected to do. They need information which features are more important than the others. They need someone to value their technical expertise and to incorporate it into the requirements.
These are the needs of the development team. The role which suits them best is the Product Owner. At the same time, Project Manager role tends to close the communication and make the development one-way process, which doesn’t help develop a working software.
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.
Who is Managing Whom?
In our industry there are three poles, each lead by a mindset significantly different than the others. There are clients, management and development. They all gather their strengths to produce software that works. But their means are different. Clients specify requirements, development produces code, and managers mediate so that the working software is deployed.
And the devil hides in this last detail. Management is responsible to deliver software. Management is signing contracts and giving promises. Then management feels the desire to manage developers more directly and to see that all that was promised is delivered in due time.
That is the point where management can take too many responsibilities in own hands and actually cause damage to the end product.
Principles of Agile Development
Only a few of the most prominent elements have found their place in the Manifesto for Agile Software Development. And that is not the coincidence. Agile development promotes straightforward management model. Here are the principles:
We value individuals and interactions over processes and tools.
We value working software over comprehensive documentation.
We value customer collaboration over contract negotiation.
We value responding to change over following a plan.
That is all there is in it. No place for endless meetings, management reports, charts and pies, plans that span weeks or even months of development time. There is no room for managers who like strict progress following. Such practices distract development and their overall effect is that the product gets to production later.
Esther Derby, agile practitioner and speaker, recently gave a brief but well placed comment on the way agile development is managed in some companies. “Many managers in organizations with traditional functional hierarchies want the benefits of agile without disrupting the status quo. Not going to happen.”
We will conclude this article in the same spirit. While practicing agile development for years, we have become convinced that the company management should manage company, rather than to manage the way in which developers are writing code.
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. A typical developer uses consoles to do work at least some of the time. It can include cmd or PowerShell for starting applications and debugging their output, git bash console or other. Solutions included with Windows are often lacking ease of use, many features and possibility for customization.
ConEmu is a great host for console applications on Windows. It means it can display output of consoles (and other applications) through it’s own UI. And it adds a lot of value while doing so.
It uses term task to refer to hosted applications. It offers an option to set up predefined tasks (hosted applications) and many of the usual ones come already set up. These include most of one’s needs like: cmd, PowerShell, Git bash or Chocolatey. It can host standard permissions and administrator level running tasks. And it’s not only about consoles. You can also include file managers like TotalCommander or FarManager, Filezilla, stand-alone source control clients, text editors or any other application. Tasks are displayed and navigated as tabs or separate windows depending on settings.
As far as using it with consoles, main idea is that it hooks up to a process, uses its console output and displays it in own window. This window is customized in terms of background, fonts, colours, width and height and length of logged output. This log is easily searchable and scrollable. It has fine performance with high frequency logging and can host console GUI applications like Git bash in some modes, Far Manager, Vim editor and similar.
Using ConEmu helps you by having all the utility consoles in one place, formatted to your liking. It automatically remembers the list of tasks and can restart them when you start ConEmu.
The author of this article is using ConEmu in more than few scenarios:
One PowerShell console with administrator privileges to execute tasks in Windows related to configuration, mounting drives, copying or setting up IIS. Another one as a support for programming and building solutions in Visual Studio – it is easy to run MSBuild to build multiple solutions (build scripts) of your source code. I actually run the same scripts that the build server is running, but in my console. This way I don’t break builds on build server any more. I also use one Git bash console for local git repository, more if working on different projects at once. I use it for reviewing status, changes, staging and committing, as well as analysing history. Other source control options such as TFS, or SVN also support this way of working. In general, most have a set of options that are only available through command line use. From non-console applications, I embedded Far Manager and FileZilla for copying, moving, archiving and backups. This way I have streamlined my build, test and deploy process.
The author and his colleagues recommend switching to consoles for performing some tasks. Once you get hooked up, it is hard to go back to GUI.
As another great recommendation Scott Hanselman, well known developer, blogger and speaker, has included ConEmu in his list of top developer / administration tools, which is available at: http://www.hanselman.com/blog/ScottHanselmans2014UltimateDeveloperAndPowerUsersToolListForWindows.aspx
Far Manager: http://www.farmanager.com/index.php?l=en
Scott Hanselman: http://www.hanselman.com/
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. Problems arise because these two parts of the larger team often think differently about upcoming work. Subtle differences tend to hide in joint meetings, just to appear in form of a missing feature when it is too late. Another common scenario occurs when client partners form an incorrect image regarding team’s capacity. Such misconceptions may lead to inadvertently giving false promises to clients.
One particular team practice that we have discovered turned to be able to remedy this unfortunate situation. Normally, tasks that the team works on are kept in the product backlog. These tasks are subject to many changes. Backlog exhibits changes on a daily basis. On the other hand there is the sprint backlog, which contains tickets selected to be completed in the current product version. The communication and planning problem highlighted above actually lives in the product backlog. With product backlog growing ever larger, the chances are that client partners’ intentions regarding upcoming versions will gradually begin to drift away from those of the development.
To address the issue, we propose another backlog to be defined – we call it Future Sprint Backlog. It is dimensioned to contain tasks for at least one and at most two normal sprints. Changes to the future sprint backlog are allowed without many restrictions. The purpose of this group of tasks is not to define team’s work for the following sprint. It is rather intended to reveal plans of the business.
Development observes the upcoming work and grabs the opportunity to estimate it. That is where the dimension of the backlog comes into play. By estimating future tasks and asking client partners to remove extraneous ones, developers are telling which of the desired tasks could be planned for upcoming versions.
This special-purpose backlog can still change. It can even be subdued to significant changes. This is because the team has not committed to any of the tasks it contains. Its primary role remains to limit the amount of work that management might commit to clients. All in order to avoid unfortunate situations when the company makes a commitment to deploy features which go beyond capacity of its development team.