Developer Manager Divide

Something inside of me was stirred recently when I came across a blog by Rob Walling, clearly Rob is an experienced and insightful developer which is passionate about his work, further he has experience the many sides of our industry.

One particular post 'An Open Letter to Software Managers of the World' really got me thinking. I have hinted at the conflict issues before in my posting that can arise between managers and developers, I feel that I have some experience in this having been on both sides of the fence.

What got me in particular about the above post was that Rob lays out a dozen or so responsibilities that managers and developers need to accept. This is great starting point, but it still has the under tones of us and them, which is the reason the list sits sightly uneasy in my mind. This all in all is not a bad thing because it has acted as a catalyst of thought and the reason for this posting.

After much consideration I have decided not to approach this issue as a developer, manager or architect, rather as a human being with a vested interested in the industry and in software engineering. So I hope to share from my perspective as that person whom has enjoyed a good living from this industry and wants to continue to do so. Firstly you would be a fool not to accept that there has been historical conflict between developers and managers.

Clearly the solution of eliminating one group is just not viable, in the words of A.Cockburn development is a game, a game that needs a group of people with various skills to work together to make things work. We need participants to map out a path ahead, others to manage clients, others cut code and ride the small details, others to deploy and integrate, others to manage and take the damage when we slip up. The reality is when the participants do act together as a team the game can be profitable and rewarding to all.

Therefore this is the first premise that needs to acknowledged, that this game take various participants with diverse skills working in concert to win. The alternative is that one can play with ones self and maintain an illusion that you are taking part in the big game, which clearly you are not.

Acceptance of the first premise leads to the question as to how do we optimize the roles and interactions between the team members?

This is where I think a common set of rules or principals might work better then a list for this type of person and another for other type. So here is my attempt to list my three key rules, explain why they are important and how it relates to the list in the open letter.

1. Understand what the other team members do.
Understand their constraints and how they do their job and what they produce when they have completed their job. For example a developer looking at a sales or business development person, needs to understand that he is out their fighting for a contract that will put food on the table of the developer, that he needs to deal with all different personality types which are receiving alternative offers. He is reject hundred of times and totally shutdown most of the time, this is clearly a hard job, he is at risk of losing his job if the contracts are not delivered and further is at risk of burning is reputation if the software is not delivered.
From the perspective of the business development guys he needs to understand that the developer has to pay the price emotionally and physically for the constraints established within the contract. It is the developer which is not going to go home at night to see their family it is the developer which is not going have time to spend they pay packets because of the unreal expectations that have been set. This applies to all the roles with in team,
If understanding and balance is not achieved between all team members, ultimately it is the stakeholder who pays the price. It is only when we don't attempt to balance profit against the human factors does the scales default back to profit, but that is not say that a profit will ultimately be delivered.

2. Take Personal Responsibility to empower other team members.
Clearly if everyone is operating at optimum levels the team overall have a better change of winning the game. I can already hear some people say but what power do I have, I am just the newbie tester. Well we all have power in a development team, and we need to use that power to ensure that our team mates can do their job better. For example, as tester I can empower a developer by really working with him to help him improve his code, I can do this not only by doing my job well but also taking responsible to communicate openly and directly and respecting the other person at all times.
As a Business Development person I can talk to the developers, architects etc before the terms of engagement are in stone and ask them how would they like to see the engagement carried out. As a developer I can work with architects, project managers and business people to come up with innovative solutions that the business development team can take to clients. As someone who has budget and resourcing responsibility over developers I can ensure that they have the best tools so they can perform at their optimum.

3. Communication and Ethics
Despite the best efforts and good intentions of all team members, there will be conflicts, stuff-ups and less then ideal situations. It is how we overcome these event that determines if we are winners or losses in the game over the long term. Communicate everything without fear of judgement or retribution, if you hear something you consider stupid it does not tell you anything about the other person who said it rather it tell you that you have failed to empower that person and bring them along with you.
Communicate in an open manner not to position others or cover your own short comings, this is the only way to build trust. If there are short coming never lie about them, highlight them, find a solution, fix it and move on.

That is it! Probably sounds very idealistic but it is applicable. Let show you using the list in the open letter.

Developers List

We will do what it takes to get the job done without being asked, including working extra hours (as long as it does not violate clause 1 in the section below).

An issue of understanding, no one should burn themselves and extra hours should be so unusual one should have trouble remembering them. (You can see the agile guy in me coming out), Communication leads to understanding of work loads and they are what they are, you can not change the laws of physics.

We will not complain when we are assigned boring tasks, bad problems, or have to maintain someone else's code (as long as it does not violate clauses 4 or 5 in the section below).

Task 'niceness' is in the eye of the beholder, I personally think maintenance work is one of the most challenging jobs one can do. Anyhow can write a connecting pool-er but it takes skill to retro fit a new database into a old one without breaking it. The key point here is understanding and communication, one just should not commit to delivering something unless you can get someone to signed up to do it. Respect means influencing and not forcing.

We will bring issues to your attention constructively and with proposed solutions.

Does not need discussion, it is about communication and ethics.

We will seek to understand a decision before questioning it.

To question is good, but understanding and empowerment would cause you are apart of the decision if it effects you.

We will build the best software we are able to.

Does not need to be stated, no person wants to do a bad job, we all need to feel proud of our work.

We will be loyal to the company and our team.

Loyalty comes as part of trust, and the only way to build that is communication and ethics.

We will be passionate about the software we build.

Needs not be stated.

We will be available when you really need us.

I will alway be available to empower a team mate

We will fully document our code and designs.

A professional would not do anything else

We will happily coach and mentor new developers.

I know I was a newbie too many moons ago.

We will tell our friends how cool it is to work at our company.
I will always to tell the truth

Managers List

You understand that "crunch time" is an unexpected part of software development. Unless we have substantial equity in the company, crunch time will not exceed 3 weeks during any 6 month period.

If I have created crunch time I have failed to understand what others do and have not communicated adequately to explain work loads etc. Just because someone has substantial equity does not mean I can drop the ball.

You will give us powerful, best-of-breed PCs, huge hard drives, large monitors, and the latest development software.

I understand that tools does not make it the programmer but they sure as hell improve productivity and I want to empower developers to be their best, for that matter I want everyone to be the best they can.

You will listen and take action when we constructively bring a problem to your attention.

Does not need discussion, it is about communication and ethics.

You will ensure that at least 80% of our time is spent on good problems.
It is in my interest to get involved with everyone and sign up for things that I think I can do well. If I have accepted a task and it turns out to be a bad situation I need to take responsibility to complete it and ensure that i does not happen again by empowering those around me with the knowledge and understanding as to avoid the situation.

If you plan to call us when software breaks, we will be given time to refactor and stabilize it as needed.

I will clearly set the expectations when I am asked to sign up for a task.

You will not ask us to serve as technical guides for highly paid contractors only to be held responsible when their code single-handedly brings our operations to a grinding halt.

So Obvious it does not need an answer.

If marketing is allowed to set our deadlines based on their knowledge of software projects, we will be allowed to set their budget and/or revenue expectations based on our knowledge of marketing.

What can I say understanding and mutual respect.

You will not ask us to compromise a solid, stable, and maintainable design in order to meet an unrealistic deadline.

What can I say understanding and mutual respect.

You will communicate expectations to to the stakeholders. You will ensure that before we begin building an application, all stakeholders spend ample time reviewing and understanding the specification.

What can I say understanding and mutual respect.

You will ensure that as new requirements arise we will be given the corresponding amount of additional development time.

What can I say understanding and mutual respect.

You will pay attention to your people more than your bottom line.

What can I say understanding and mutual respect.

You will make our company a cool company to work at so we're not lying to our friends.

Never Lie.

Now this sound all very new world and nice, caring and sitting in a circle and meditative.

It is not unrealistic, it can all be achieved..... Yes there is a missing piece from the above but I have told you plenty for you too put your heads together to work it out. I will even give you a clue.

There is one extra thing you need to do on the commercial side to make it all work.

Basically if you can answer the question you have team that could win in the development game, if you cannot, it is time to start understanding that you might need others on your team.


Good Luck

The Code Base is an Asset

Having recently completed a maintenance engagement, yes architects do get involved with maintenance, hence I am going to use this posting to rave on and on about code as an asset.

The concept of custom developed software as an Asset totally escapes most organisations and as result of poor asset management, they end upstanding under the shower ripping up hundred dollar bills to keep their software applications running.

In my example, you have an organisation that has developed an online application to facilitate the exchange of information between thousands of commercial users. The nature of the exchange means that there are financial impacts for the users and the application host, so there is a degree of motivation and funding to keep the application operating.
Here is the amazing part; they invested large amounts of money in building the application but did not give one thought to how they would keep the application running and evolve it to meet changing requirements.

The strongest evidence of this was present in the code, you could see how things began, there where unit test for all the early functionality, the naming convention was clear and the design of the application appear to be thought out, and the underlying theme was MVC. Then you could see the first round of changes to the application, which was a walk on the wild side, the second around trying to keep with the original approach and the final around, was a perfect demonstration of over engineering. The whole concept of less is more had escaped some of the folk that worked on this application.

So why does this matter, if the application is doing its job and working why are you banging on about all this internal stuff. Simple it effects productively and productivity equals dollars, in other words you end up paying over the mark not by a little but by a ton, are you interested yet?

Now it is easy for me to sit here and say folks should be more professional, but that is unrealistic, often the developers who work on this stuff have ten or least years experience in the industry they are not aware of how terms of engagement can affect their output let alone know how best manage these situations.

The root cause for the above problems which results in wasted dollars on maintenance is ignorance, ignorance of the promise of OO and how to harvest the benefits, ignorance that code is an asset and it can be and should be managed like any other asset. Let us get practical with an example, Application A has taken 3,500 man-hours to build at a cost of about $612K dollars, there is annual hosting & operating cost of $25K (excluding software maintenance and changes cost). This plus the depreciated cost of the development results in $230,000 expense on the P/L annually, this is the start of the hard questions.

Is the system meeting its financial and operational objectives and at what level will it start not to meet those objectives, if maintenance cost rise (putting aside changes for the moment as they normally come with their own set of productive gains or new revenue opportunities).

This is starting point for a software maintenance programme; we need to be able to say if we send more than X this year on maintenance of y over the next z years (z being the effective remaining life of the application) then the viability of the application is under question.

From here, a maintenance strategy can be constructed, which is based upon a code audit, which identify areas of risk, these can then be proactively refactored to mitigate the risk arising from them.

This is a good time to share you with you the number one question I am often asked about maintenance as separate issue away from change. If the application is working well now, why would it break and if there is no reason for it to break then why carry out maintenance?
It is actually a very good question, if the application is running well now and has been for a while, then the risk of it stoping or breaking tomorrow morning is low. That is not the type of risk maintenance looks to mitigate. Maintenance focuses on parts of the application that can break easily when change occurs, for example, let say that backend database needs to be upgraded or a new functionality needs to added, the application should be in such a state that those changes should not break the application.

Another practical example let us say a new feature needs to be added to the application and the original estimates where 20 hours work for the implementation of this new feature. In implementing this feature using best engineering practices, the security mechanism of the application is broken and to change the mechanism so it can work with the new feature will require 80 hours. All of sudden a 20 hour improvement has turn into a 100 hour job which could render the new feature uneconomical to deliver, after all 100 hours is about 3% increase in the total hours invested in the application.

In a refactoring situation, parts of the security mechanism can be changed at a leisurely pace without needing run resources in parallel to meet the deadlines. It still might result in 80 hours work but it cost dramatically less due to resourcing.

I hope this posting can help you see how quickly maintenance can get out of control and why you need, a plan and ideally locked in contracts with vendors prevent these situations from arising. If you know the risk, you can transfer it to a vendor.

The Process Value

Real World Software Architecture: Thinking Software Development Process Implementation is Free means the Blind are Leading the Blind, but there are Ruby Slippers that may Help.

This posting has been triggered by a very interesting posting I read on Tad Andersons blog, Real world software engineering, about development processes and more to the point the implementation of process within
software development organisations.

This area is of particular interest to me, like tad I have considerable experience and night mares surrounding methodologies and processes. But rather then extending upon Tad posting or echoing all his comments, which I agree with 100%, I intend to cast them in a different light, from the perspective of a business model for software development.

So before we jump in I will outline some of the fundamental principals upon which all my arguments rest:

1. The development of software is not a simple undertaking which succeeds without a formal plan and map as to how the ‘application’ is going to be built. Other words one can not just sketch out a few ideas and expect a developer to sit there and turn out a fit for purpose functional application.
2. Methodologies with proven track records do exist, which when applied correctly will allow a group of people to collaborate and deliver software applications.

Therefore an organisation that’s core business is to develop software application MUST has in place a highly developed process, assets and tools, as nothing is for free in this world the organisation must of invested hard dollars in their process.
To directly answer Tad’s question “What makes people think a Software Development Process can be implemented in an organization at no upfront cost (including time & money)? They think this simply because either they are poorly informed.

To understand this further lets take a healthily business model of a software development firm. In the past when I have sat down with this type of companies and ask them how do they think they make their money, the answer I get 75% of the time is “we bill our clients for our work”, my followup to this answer is “what margin do you work towards” and from here I get an answer that range from 30% to 200%.
My next comment is what normally upsets everyone in the room, “So your company makes money by hiring people and billing them out for cost plus X%, so in essence your company is a body shop.”
“No you don’t understand” is normally the objection; then they try to explain that they are a technology company and how they have processes, intellectual property, etc.

The reality is that most software firms out there are body shops, in that they only profit from margins on human resources, now that is not to say body shops are bad or useless, this is far from the truth, but they are also far removed from what I call a software development house.

From my perspective a software development house is an organisation what can deliver to their client’s, custom software application and/or solutions, for a cost what is lower and a quality which is higher, then if the client decided to put together their own development team to build the application. So how does a company achieve this, well it is via processes, assets and tools. Before drilling down too much lets take a look at a manufacturing company in particular one that specialises in die casting.

That factory, besides its staff and raw materials, would have a large amount of infrastructure they have invested in, infrastructure that would allow them to manufacture components quicker, better and safer.

The same applies for a software development house, they would not have only invested in their people but they also would have invested in a process/methodology, which is akin to their production line, they would have also created specialized tools and that would have framework components they can reuse.This allows them to produce code quicker, clean and much more reliably then the local software body shop. Hece gainig a competitive advantage.

So from my perspective it is probably the body shops that want to implement processes and due to their culture and the nature of their business expect or don’t want to pay for it.

The other area where software is built which I have not covered is within organisation’s which core business is not software development. For example an Insurance company, their core business is underwriting and risk, now that business would have plenty of smart folks and financial resources to develop software in house, but would they want to? After all they don’t make money by producing software.

Given there are situations where they could develop in house and most of these situations would probably relate to non mission critical applications that delivered productivity improvements rather then core business operations. In these situations they would still put in place processes to protect and guide their investment in the code base that will develop of time, methodologies like Agile and XP are just so fitting for most of these situations.

In conclusion I believe it is clear from the above, Tad’s posting and other published resources that you must have process /methodologies in place to turn out quality reliable software and that the processes themselves are a competitive advantage in the right business setting.

Coding outside a methodology and a architectural pattern or paradigm is something for strictly for the weekend coder, and if the business can not operate on that basis then get professional.