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

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.

Software Architecture within a Commercial Context

Inspired by a recent post by Paul Reedman I was driven to make this response, before diving in let me go on record and say that having been a readers of Paul’s Blog for while now I usually find myself saying ditto to all his post.

But this one and in particular the responses which it generated has fired me into action.

The line "In the software industry it's all about writing code and getting a product out the door. Good design and architecture has disappeared." Sends the message, to me at least, that somehow we have sold off good design for the sake of money or commercial pressures.

I can understand those comments but I also need to say that is not way it has to be, in fact it is only that way in some organisations because us as a group of Software Architects have not been innovative enough to prevent this from happening.

My view point is this, Software is developed within a commercial context and the commercial model of supply, demand and free market forces needs to drive everything we do. Recent history has shown us this is a force that can’t be resisted.
So as Architects we need to embrace this reality, much like many of us have embraced change as a fact of every project we all need to embrace commercial constrains of time and budget and design around it.

Now that does not equal compromise rather it should cause us to innovate. Let me share some experiences here in short form, I will save the details for a book, or for the next time we have a drink together.

• Just Like Any Other Feature - Get the time and budget constrains into the project requirements and map the relationship between other constrains and these commercial ones.

• More bang for the buck – Everything needs to used more than once, write development documents that can be rehashed for user documentation, use API test suits as a basis for API Client libraries, practice OO reuse all the time. (Email me if you want more of these ideas I have hundreds)

• Less is more – Be strategic why spec two functions that have 70% overlap, give it one use case and extend it, same applies at implementation stage.

• Use a pattern – Patterns are distilled experience which is free and only have a positive impact on the project, so understand them and use them all the time.

• Parlay It Up – Stop looking at projects in isolation, ask yourself what is one thing we can do that will have less than a 1% impact but give us some value that we can use in the next project. (Poor man’s framework and code base)

• Don’t remake the wheel. For the pride, if there is a third party component, server, application, API, whatever that can help you deliver; trade some budget to save some time. Clearly do this with care; it can work out if you do your homework.

• Show me the Money – Releasing early and releasing often not only keeps a client happy but can work to simply your project. Something magical happen you make the client live and breathe an early version of the application. They start to discover how they can optimize the functionality and this can highlight the useless stuff that can be cut.

Now that I made all the motherhood statements let me hit with some hard realities. You cannot change the laws of physics; total project budget divided by time constraint divided by the number of plan iterations will always limit what one can achieve.
The defining factor of a software architect and where the art comes into it is how much you can achieve with what you have to work with.

Software Development Analogy

There has been much debate of a simple analogy; that building software is like building a house and that software development is like construction. Having read and considered the all arguments surrounding the software construction analogy and given that both camps have appeared to rest their cases, it was appear to be an opportune time to reach some kind of determination on the matter.

In commencing, we need to recognize the contribution made to this debate, each party drawing upon their clearly extensive experience in the area. Both Glen Alleman (Software Development is similar to Construction) and David Anderson (Construction is nothing like software development) have put forward some interesting points.

Not least of which both parties are searching for an analogy, which in itself is very enlightening. Clearly this is complex area hence the need for an analogy (I think this was the frist use of the analogy)to explain to those who may not have had firsthand experience of software development, be it a simple systems built by the collaboration of a few or complex systems built build by the determination of hundreds.

The pro construction analogy camp has delivered some very good insights, namely that the design changes during construction, leading to a disparity in “As Designed” and “As Built”. This being the case there is clearly collaboration and client interaction at play in the construction game.

Like construction change and client interaction are prevalent in software development, resulting in what can be a disparity between “As Designed/Specified” and “As Delivered”.

The against construction analogy camp has highlighted the issue of iterations, which unfortunately both parties have managed to pervert to some degree. Using the example of delivering only a working toilet in the first iteration does not fairly highlight iteration in the construction game. Similarly, the pro camps have not done themselves any favour by not elaborating or responding to this point. Not to do their jobs for them, much could have been made of the fact in construction there are often things that either near completion or completed, then they are required by the client to be change or ‘extended’, clearly this is a form of iteration. It is designed, built, looked at by the client, redesigned to improve upon it and then it extended or rebuilt. In these ways, it is clear that construction and software development share some similarities.

At this point the similarities end, construction is a physical pursuit and has its unique set of constraints whereas software is an intellectual pursuit having its own set of unique constraints different to those of construction.

I am sure that both camps would agree that there is adequate degree of complexity in software development and that the amount of capital invested in it annually justifies a description of it, which is not as over simplified as that of constructing a building. That is not to cast doubt of the complexity of construction but I hazard to guess that construction is better understood then software development.

A more fitting analogy of software development would probably be along the lines of a cooperative game subject to the constraints of game theory, which unfortunately is less understood then construction and software development combined.

Not to steal the thunder of an argument comparing software development to a game, refer to the presentation given by Alistair Cockburn at the 1999 ObjectActive Conference. Possibly dated by now but does highlight some unique point’s particular to software development.

The above work was also recently rediscovered by Jeff Atwood and has created equal amounts of debate.

So I hopefully I have put to bed the construction analogy, yet I fear I might of just of opened another can of worms in the process.

People are amazing

I can feel a nightmare coming on.

I promise I am not going to name any person or organisation in this posting, oh how I wish I could.

Just know that in the best firm’s ugliness is only one thought away.

So I sat there today for two hours hearing about this great product idea and how after it is developed the company is going to have a massive strategic advantage. Then I made the mistaking of asking a questions. It was a simple question “At what point would development cost and time start to destroy the competitive advantages that are envisaged?”

I got into world of trouble, it turns out that decisions had already been made and meetings already held, external consultants engaged and internal developers mobilised and all parties agreed that the application could be build with no problems.

Therefore why was I going to make a fuss out the issue, well it turns out that I was not the only one in the room shocked, the other parties where the development manager and in-house architect. Let me take a moment here to state clearly this was not a power issue, many projects originate in this organisation via cross channels and it is something we encourage.

The shocking part was that the folks involved here where relatively senior but failed to ask the most simple of questions because there was so much collective buy in. Later during the day when I spoke to parties involved, I found “I thought...” and “He said....” all over the place.

Basically what happened here was folks brought into the concept based upon the creditability of the others people who had already signed up. What the project sponsor had worked out in a non-deliberate manner was that there was a chain of creditability that was not clear to others, basically he worked out that if B was onboard and thought it was a good idea because A was onboard, C got on because he thought if B was there it must be OK and the chain continued.

If the sponsor would have changed the order then the project might have been stopped in its tracks or at least would have been thought about in detail.

The point here is there was many themes at work in the process, some folk what to form a tiger team to do something, others had a tool or technology they wanted to try out, others wanted to reduce the specifications right down and others just wanted to keep the managers and architects away from the game, all reasons I can understand.

Often what escapes all these folks is that software development is a high risk game and sometimes the best way to win it is not to play & other times defining the limits under which to play is actually the best chance of winning.

There are heaps of examples of the hate or avoid the architect scenario, but on the whole I don’t think we are too hard to work with, yes sometimes we have a different perspective or different driving pressures.

The best advice I can give developers when dealing with their architect is the same I give architects when dealing with developers, first understand them as people, see that they have faults and strengths, ask them what are their driving factors and seek to work together in a fashion to carry each other along.

Lying Resume

Real World Software Architecture: Frauds- Liar, Liar, Resume on Fire

I am starting to think that is an international practice, having worked on three continents I have found this problem everywhere and I have also developed my little theory & solution.

I believe the problem begins with the placement firms/recruitment agents and the job descriptions we provide to them. Let’s say I need to take on another developer, so we shoot of a Job description to the recruiter saying something like:
Java 3+ years, Corba 2+ years in a Sun Environment, UML or other formal methodology, Oracle.

I can be assured to receiving a heap of CV’s with the words Java, Corba, UML contained in the text, it is almost like they OCR all the CVs and keyword search them. I say this because the time I have include terms like ‘comparable OO languages’ or ‘competing processes’ I don’t see resume with languages like Smalltalk or Agile methodology come back etc.

I know that this is a big conclusion to draw from such a simple test but that is what my gut is telling me. So if this is the case I think the developers out there are feeding the CV monster just to get to interviews with the hope they can turn things around in the interview.

So these days I am trying not to put people in that situation, I am telling the agents that if they are wasting my time, defined as sending me ‘padded’ CV then I will not deal with them and I also keep my set of requirements short and to the point.
It is sad that we have to pay large placement fees but still have to waste our time. I make it clear these days that I will flight on the fees if I receive padded CV’s. I suppose the other issue it there must by good people out there and if they are not playing the game they are probably not getting the interviews.

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.

New GUI Methodology - XAML it..

Having recently completed a project where we handled the conceptual design and functional design in a new way I thought it would be of benefit to share some insights.

The application was for the visualisation and manipulation of large amounts of transactional data, besides the technical challenges which I will attempt to covering in another posting, we needed a method to explore and discover the optimum way a user could interact with the data.

Using a form or grid approach was out of the question due mainly to the vast amounts of data and the requirement to allow the user to turn that data into usable information quickly and build upon pass decisions as to the mean of certain data.
Traditionally I would have solved this problem with hand drawn story boards showing user interaction and application responses; from there we would proceed to UML or simular to formalise the application behaviour. As I have used this approach a number of times & I have rather perfected it, for example using a sketch artist rather then an analyst or GUI programmer is the key, due to redraw and exploration times, but that is the subject of another post.

This time we took a left field approach due to the complexity of the information model and need to reiterate UI design quickly, due to you guessed it time constraints. So we swapped out our time risk for some technology risk which we felt we had a better chance of managing and used Microsoft Expression Blend, which was still in beta at that stage.

Expression Blend is an IDE for generating XAML which is Microsoft’s new unifying technology to bring together such things Forms, MFC, etc. Again the XAML technology itself could fills its own posting easily but for now I will focus on the experience in using it to implement a commercial grade application.
Clearly to start off with we need to get out heads around the technology and the tool, luckily we had a head start in this area because we followed XAML’S development very closely. We then need to setup a work process so we could have very productive sessions we resulted in hard deliverables.

We commenced this by generating a template collection in Expression Blend covering everything from standard controls to colour schemes, as Blend uses a simular approach as style sheets for these petty bits it is quick an easy to swap them out to suit the users driving design.
After we generated some base templates which represented our first attempt at the GUI we sat with users over a number of sessions and build the GUI right in front of their eyes, we where able to build interactions and responses using the animation timelines in Blend.

Users could see how things would look and feel, how they would achieve certain task and how the application would dove tail into their processes.
What we learnt via the process is that the task of crystallizing functionality, merging simular functions and removing defunct functionality happened very quickly and another benefit was we achieve a user interface paradigm that was very tight something that you would not normally see until a few version down the line. This of course is to say nothing of the time/cost savings and the total removal of developer rage.

Once we achieved the desired outcome and by in that the GUI we developed represented the full set of functionality for the application, it was time to get our hands dirty to make this thing work.
This was the point where the approached delivered real benefits, during the early architectural stages we decided that the application was going to implemented using a MVC (Model View Controller) pattern so all work on the GUI did not have to thrown away, we could hook up objects in the GUI to Objects in the Controller.
The big difference here being the XAML assets we created in the user sessions could be directly contributed to the final application, no need to write from the ground up.

Looking back I would have to say that this approach was quicker then other approaches which I have tried, storyboarding, GUI prototyping and certain wins hand down over written GUI specifications. My greatest initial concern was that we would not have anything to test the GUI against, this was clearly not the case, we ending up with a working prototype that we could easily test delivered function A against Prototype Function A.

The downside was mostly related to the fact the EDI Expression Blend was beta version, since which time I have looked at the release candidate and have been impressed.