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.

Passing Note

It has been a couple of weeks since my last post and every day I have been telling myself I need to post. Well today, well this morning, well in the next 15mins I have feel I thought I would do a quick note to let everyone know what has been happening.
I have need rushed off my feet of late with projects so there will probably be some interesting post in the next few on web services and as I am doing some WCF stuff it will be web services the Microsoft way.
The troubling thing is that I am still seeing bad OO code, one of the projects I have been working on is a maintenance and extension job to an existing web application. Nothing fancy just Oracle, Beans and JSP in a MVC pattern ‘Struts’.
Yet again, the team that cut the original code throw out all the benefits of, of the hundred or so classes, only a handful have been extended, everywhere else good old copy and paste, almost brings me to tears. The result is that they are creating more work, which does not necessary equal productivity, hence not adding the GDP.
Oh well I know I could write two books about the subject but for now I have to move on, and kill a few bugs.

Leveraging Google

With the buzz about Web2.0, Mash up and SOA, I thought this would be an opportune time for a quick post on how an enterprise can leverage Google so that can go where no man has been before.

When we think Google we think search and rightly so they have had a major impact on that landscape, but search is not the only thing we should think. As of this moment there is probably some half dozen other major Google online applications which is not within the primary search space.

These applications which I am not including with the primary search space are Google Documents, Calendars, Base Data, AJAX, Checkout, Email and Blogger. If you include the rest like searching, mapping, ad words/sense, etc the list just sky rockets. What is more important is that Google have developed stable and well documented API's for these services.

Google clearly want folks to build applications that use their API, because these become additional channels, channels which are very sticky simple because once an organisation invest in learning and implementing an API they happen hang around for very long time. That said and understanding that one could spend a whole posting on the commercial issues, let move along to what we can do with this stuff.

Via the Google API's all of the Google Services have become 'Web Services' therefore a custom smart client or web application can be written to replace the existing heads. This in itself is not very interesting, given that the Google interface is so functional. The next step is integrating single services, like the Google Check service, which in short is a merchant facility for online transactions.

The immediate benefits are clear here, reduced development time and you get access to a bullet proof facility, but go a step further and use Google Spreadsheets Data API and you can easily hook-up a whole reporting and management system which produces Graphs on sale numbers and operational targets.

Another Cool combination would be to use the Gdata API to store the products online that you would like to sell. So all of a sudden you don't have to maintain your own database, Google is doing for you and somehow I think they can do a good job of it.

List of possible uses are almost unlimited, you could use blogger to data amongst a group of analysis, data which can read by a human eye as well as being machine readable. Anyhow as you can see the list could continue forever. As a thought exercise image a desktop smart client application that relied on web services for all it' s major components, how things would change not only in what we could do but also how quickly we could do it.