Software Development Management in 11 steps

What it takes to be a great Software Development Manager? I have been building software for the last 15 years and have collected a few stories and experiences to share. Some I have used as questions when interviewing candidates. In 11 points, this is my story to date.

 

1 – How do I know that my development team is producing quality work?

Define Quality.

If quality is a reflection of a reduced number of bugs in the product, metrics exist to measure this information. If quality is an expression of non-functional requirements like performance, security or accessibility, independent tests can be executed to validate the work according to these parameters. If quality of work is a metric of readability, maintainability and loose coupling of objects in the source code, tools like Visual Studio provide deep insights into such values.

In my long experience in professional consulting services, the most common definition of quality is driven by customer satisfaction. Doing the right thing at the right time is indication of quality as perceived by customers. Quality is subjective to the purpose. Happy customers will regard your product as a qualitative one if it does what they are paying for. They may tolerate bugs if they see commitment to get them resolved quickly. They forgive poor performance if the software does the job right anyway. They are happy to pay for longer upgrades if they see a value in the services provided.

 

2 – How can we automate more of the day to day, how do I optimize my team’s expertise?

I am a strong believer of automation in software development and testing. I employ automated tests on a regular basis for unit testing (Microsoft Unit Testing Framework), functional testing (Microsoft Test Manager) and load & performance (Visual Studio Web Performance & Load Test Project).

Also the development phase can have a level of automation by using tools for peer code review, like FxCop or Resharper, i.e. tools that help to write better code by providing patterns and templates ready to use, or verify that the existing code complies with policies of good practice.

Teams benefit from automation in having more time to focus on what really counts, leaving the routine of writing code to the tools, but still maintaining control on the output.

 

3 – How can I get more velocity?

Do more by doing less in the same unit of time. In the old age of PC, there was a long going battle on which communication bus would perform better: serial or parallel. Common sense would say parallel, as you can do more things at the same time. Reality is that USB is the predominant bus used in today’s computers, and USB is a serial bus optimised for point-to-point speed.

The principle is simple: get one work item done as soon as possible. Focus on it and get it done. I use Kanban as an agile practice for pulling a work item into the development pipeline from the product backlog, and focus all efforts into completing that one work item. Any further work is undertaken only after the current work item is complete. Obviously, in presence of more than one team, multiple work items can be developed at the same time. Git also eases this process by allowing multiple work streams in individual branches of the master code.

 

 

4 – Should we outsource? Buy? Or build and in what location?

Difficult to answer without context, it really depends on what a company is trying to build. Before being able to recommend any approach, I would need to know more about the product vision, the market, the capacity of the team.

I have experience of successful collaboration with offshore teams. I summarised my experience in a blog post (The Art of Outsourcing Projects), available also on LinkedIn Pulse.

In a nutshell, outsourcing does work. Managers just have to figure out the right techniques to master the obstacles.

 

 

5 – When is too much “craftsmanship” too much?

I don’t like putting limits to creativity and “entrepreneurship” in software development. At the same time, I like order and processes, without this affecting the capacity of teams to apply their personal touch in the work they do.

I have managed teams of software developers and web designers leaving always a balance between productivity and creativity, allowing time for research of innovative concepts, and investing myself into alternative ways of human interaction with software application by using, for example, mobile devices and the Kinect sensor.

One of my preferred success stories is the Friday afternoon allowance: no more production coding, but rather focus on research of something different, not used daily, in software design and development. Outcome of this “free time” was highly motivated team members, who see their creativity appreciated; knowledge sharing, with people keen on sharing their findings with the rest of the team; and innovative ideas turning into products, by introducing new cutting-edge technology.

 

6 – What does “done is better than perfect” mean to me?

I strive for perfection in everything I do, but I am also a very pragmatic person and apply my realism to my management style. No software application is immune from defects, and having bug-free delivery as a goal is utopic and unrealistic, and counter-productive on business and teams too (it kills speed-to-market and team morale).

Realistically, I want my delivery to be as perfect as I can in the given time frame and available resources. Meeting the set KPIs and quality requirements is my definition of “done”. Additional iterations may be spent on perfecting the outcome, until a full satisfaction of all stakeholders.

 

7 – How do I keep highly marketable developers motivated and passionate about working for me?

Every individual is an… individual! And as such, they are motivated by different means. I managed teams in the excess of 20 people, onshore and offshore, and I have always applied my golden rule of getting to know people personally, one by one, understand what makes them wake up in the morning, what motivates them and how to get the best out of them.

Contrary to common belief, not everybody is motivated by money. Lot of people I have the pleasure to work with, are motivated by recognition and visibility, career progression, professional and personal development (never underestimate the value of sending a person to an industry conference for a day or two!) and even travelling and networking opportunity.

Getting to know each person individually and creating an agreed development plan is key to retention and motivation, in my experience.

Allowing for research time and the possibility to work with the latest cutting-edge technologies is also highly motivating for software developers, with the advantage of bringing new skills and expertise in the “regular” product development cycle.

 

 

8 – How do I maintain a great relationship with my business stakeholders?

Communication is key. Clear, frequent and transparent communication to all stakeholders about progress, obstacles and opportunities. Communication should happen in person when possible, and by submitting regular status reports when necessary.

In my experience, I engage customers in regular updates and “beta-programs” to incentive them to try our products and provide regular feedback.

I communicate internally within my organisation with daily direct (verbal) interaction with people in my close team, Skype calls with offshore teams, and weekly meetings with management. I also value importantly the face-to-face meetings with offshore teams on a regular (say quarterly) basis.

 

9 – What’s the first step in transforming a legacy code base into the application of the future?

The first step is understanding the benefits of the transformation. Do not change for the sake of changing. Do change for the added value that change brings. Once understood the benefits, build a plan around them, how to get from A to B, define time frame and resources, identify risks and mitigation plans.

Code refactoring is a possible approach when the underlying technology allows an incremental transformation (for example from ASP.NET Web Forms to MVC).

Redesign and recode by leveraging the existing IP is an alternative approach when there is a breaking condition, as in a change from legacy ASP to ASP.NET.

I have an experience of redesigning and developing a troubled web application from ASP.NET Web Forms to MVC. Business logic was mixed to data access in the Web Form codebehind classes. The application would not scale (incorrect use of session and HTTP context to store volatile information). Its performance was awful (massive viewstate causing web pages to be ~2 Mb each heavy), and accessibility was limited (no responsive design, no mobile access, no cross-browser compatibility). I worked with the team to identify all these points of failure, and prepared a prototype that implemented the latest technology frameworks: ASP.NET MVC, Bootstrap for responsive design, WCF first and Web API later for the service layer, separation of concerns among presentation, business and data layers, aspect-oriented programming and inversion of control with Microsoft Unity for decoupling objects’ dependency, hosting in Azure for full elastic scalability. Result: a highly scalable, performing and accessible application in less than 6 months, with the necessary ground and technology for future extensions.

Layered software application design.

 

10 – How do we get to a point where we release on each commit?

In my experience as Head of Software Development, I turned a strongly release-oriented software development lifecycle, to a fully continuous deployment flow of a SaaS application. There are different aspects to consider for a successful continuous delivery:

1.     There is no separation of responsibility on the work items to deliver between developers and testers. Everybody has ownership of the product backlog item that they are working on.

2.     The Kanban agile practice eases this process, by focussing resources on precises work items, which are in the development pipeline until “done”, and ready for commit, i.e. deployment.

3.     Automated testing is in place: I employed TDD practices with Microsoft Unit Test and Rhino Mocks, as well as semi-automated functional testing using Microsoft Test Manager and Selenium.

4.     The proper infrastructure exists to support continuous deploys: I led a project to migrate a web application from being hosted behind the firewall to a full SaaS in Microsoft Azure, and used TFS integrated with Azure.

5.     Last but not the least, proper comms is in place with Sales, Marketing and Support to align the entire organisation with the new functionality being released on a constant pace.

 

Last point about communication extends also to Customers and relevant Stakeholders. Once I received an email by a customer who was panicking because we didn’t go-live with the new release of the product in time as previously communicated. We missed the deadline by a few days (brown stuff happens, you know…) and he was concerned about our team and wondering if everything was ok, sincerely. Not even worried about the product itself, but more about our stability. After that, I introduced a “release train”: that’s a Swiss train, it’s always on time (as opposite to trams in Melbourne J), it departs always at an agreed day and time, and it carries whatever we (the team) load on it. That means that the release cycle is fixed (time is our constraint, which reflects in predictability of product releases), scope may change, and we do not compromise in quality (we ship only features that are “done” and have passed our QA – otherwise they miss this train and board the next one). By doing this, and by being extremely predictable on our product release cycle, we built confidence in our customers on our ability to deliver. More frequent is better than just “more stuff”, trust me!

 

 

11 – What is the perfect workflow for Git with large teams?

Git is a distributed version control system, as opposite to TFS, which is a centralized version control system. As such, developers clone the entire source code repository to their machines, including all of the history. The big benefit is that you can commit changesets to your local repository without ever talking to the server or inflicting potentially unstable changes on your team (i.e. breaking the build).

A typical workflow that I use in my team for feature development is:

1.     Create a private branch off a public branch.

2.     Regularly commit your work to this private branch.

3.     Once your code is perfect, clean up its history.

4.     Merge the cleaned-up branch back into the public branch.

 

The idea is that all feature development should take place in a dedicated branch instead of the master branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means the master branch will never contain broken code, which is a huge advantage for continuous integration environments.

 

12 – To be continued…

The story does not end here; the experience carries on and on…