simondelliott

Testing a continous integration setup

I found a soultion to a problem testing CI, and I wanted to share it with you.

Im really into Continous Integration as a method to increase product quality and decrrease time to market, but I have been struggeling with creating a sand box where new ideas could be tested.

This is because the setup (developer work station, svn, cruise control, jira, test, stage and production environments) uses manny bits of kit and its not easy to tinker with all of them at the same time.

The solution I found was to use Virtual Box (sun opensource virtualisation) to emulate and run all the diferent instances on my laptop.

an added bonus was that I could just copy the files (one for each box) and share it with my developer buddies, who could see the idea without mis interpreting my meaning. They gave some excellent feedback too.

Im guessing that there may be thousands of diferent ways of acheiving this. I was wondering if you could share your thoughts on this subject?

What happend whilst you were Whilst your on the golf course.

Ive just read this article and …. this point of view is totally out of date

http://feeds.feedburner.com/~r/silicon/news/20/~3/398719685/0,39024673,39289155,00.htm

The author of this article says that there are only three successful collaboration technologies that penetrate the boardroom Lotus Notes, Microsoft Exchange and the BlackBerry.

He has omitted the Internet, the penetration of which is so complete that it is easy to overlook it. If you include it, you will see that it shows the results of many millions of different collaborations using tools like wordpress, joomla, svn and good old notepad.

The generation of people who make the 99% of this content not only reject playing golf as a way to communicate, but they also reject the notion of a boardroom.

The exclusive and location static nature of the “boardroom and golf” means of communication is in comparison to the “basecamp and msn” form of communication, far slower, which all things being equal places the boardroom style of business at a commercial disadvantage.

If the author of this article is looking to the future of business, then he (Im guessing he is a he) should be looking to the technologies that are going to replace the boardroom not those that are going to get past its security coded doors for the short time that it still exists.

I do enjoy golf

Technical architecture drawings

Firstly I am a big fan of pen and paper.  A blank sheet is the best tool for a clear mind.

Secondly, index cards …. I use these almost every time that I am designing, you can CRC card with then, you can story card with them, you can plan a presentation with them, you can use them to carry water, you can support heavy objects with them …

For flow diagrams or software component diagrams I deliberately try to keep it simple and just use shapes in Visio, or Open Office.

I do however have a large number of shapes that I have made over the years, its a good idea to start collecting these as and when you make them. It really cuts down the time to make a diagram if you have a good libuary.

After a traditional flow diagram, the diagram that I find best describes a step by step procedure is a sequence diagram.

These diagrams are great for both software and people process and can often help to find glitches that cannot be seen with a traditional boxes and lines style flow diagram. I also find that when you talk someone through your thoughts with a sequence diagram, it really gets them to lean forward and understand the concept that you are trying to convey. I used to just draw these with either Visio or a proper drawing package (Flash, illustrator or Photoshop), but now I use umbrelo.

I recommend to any professional that uses diagrams to convey complex ideas, that they simply learn the standard drawing package, which is adobe illustrator. It is reasonably accessible to the beginner, but it can go much, much further.

Your diagrams will look much better
and as diagram styles change faster than drawing packages, over your whole career you will have less learning to do.

I prefer to use a wiki to publish the diagrams so that when others see them it invites them to comment and contribute to the problem that is being described. When you do this you invariably find that you have to render the diagram to an image so that it displays on the web page.

To make life easy for the possible contributors I have found that I have had to simplify the tools that I used to create the diagram, photoshop is a good choice as nearly everyone knows the package, but I guess visio would do just fine.

Design simplicity and the trouble with requirements.

I design products are either highly involved with the user interface on consumer devices or designing web portals that sell consumer media products, and I keep coming up against requirements wars.

The problem that I had with “requirements” was it was always less risky to add to them than to remove them. Political business people who did not care for the consumer user experience would often pile in a whole shed load of requirements that in some way benefited their department (sometimes this was just to halt development till their department could publicise a rival solution)

Inexperienced product managers and marketing people who were uncertain about user behaviour would always add bells and whistles till the original product concept was hidden in a miasma of crap

The result was always the same;
A requirements document that was compromised, with no design simplicity.

This often resulted in commercial failures, and blots the good name of my development.
Where as … the things that we “just did” and that managed to get highlevel backing often made headlines and were always met by rave reviews.

Agile offered me mild relief, as I could control scope or even back out of committing to products that were clearly plagued by too many stakeholders and requirement bloat, and I could do this even after development had started

The problem is that someone who is seeking to mitigate risks will see a small requirements set as a risk, where as this is not compatible with reality. Design simplicity is a great way to reduce risk, it is also a great way to make “nice to use” products.

My belief is not that it was the process of requirements gathering or the format of the requirements that causes the problem, as I over a number of years I changed this again and again trying to improve the number of hit products.

What I want to be able to understand is how the traditional requirements gathering procedure is compatible with increasing the risk so that a company can be commercially competitive?

A happy motivated company that is making good products operates at the highest comfortable level of risk.

The solution is … don’t have the traditional approach to requirements, make a list if you like but certainly don’t use it as your major design document. Instead make a diagram or picture or animation or movie or podcast or wiki or even code – any thing that best expresses the essence of the design

I want to Chrome, I want to go Chrome

We have lived with Google chrome for nearly two weeks and everyone is talking about it.
Half of us think it’s great, the rest are wondering what Google are doing with their data.

I’ve been looking at it and I have to say that it’s a great product, the design is sublime, it installs perfectly and it works on all my personal and work systems. To be impartial I tried to install IE8 but it never even got past the company firewall.

The release of chrome is shows that we have not only left the old world behind but that we have arrived somewhere new. Innovation lead companies like Google are taking on the old process lead companies like Microsoft, as Dorothy would say “Were not in Kansas now Toto!”.

One last question … What If Google really is evil?

Computer architecture?

What is the difference  between an architect and a programmer?

The metaphore of considering a large system to be a building a very close, and extremely accurate simile. However real architects have spent many thousands of years defining and expanding their craft, but in essence a computer architect is performing the same role as building architect, it just that all his or her tools are only 30 years old.

Gaudi did not know how to fire a brick or join a staircase.
Burnell did not know how to weld a joint or lift an key stone
Eiffel did not know how to roll an RSJ or pin a steel plate.

They designed using abstraction, and the forms they designed are a meta abstraction on the skills of the craftsmen that made them. Computer architecture is the meta design above the logic of coding, integration and configuration. Programmers and script kiddies are artisans rather than architects. The currency of the architect is form and function. The architect has to trust the artisan to implement his or her vision.

Using a Wiki to create a bid responce

A wiki is a collection of web pages designed to enable anyone who accesses it to contribute or modify content, Wikis are often used to create collaborative websites and to power community websites. The collaborative encyclopaedia, Wikipedia, is one of the best-known wikis. Wikis are used in business to provide intranets and Knowledge Management systems.

When you read some ITT response documents you can see the joins,
i.e. you can see the writing style change when you look at the deferent sections

This is because the bid manager breaks up the response into chunks and allocates a team member to each chunk. The team member then works independently on the chunk. And if you are traveling fast then sometimes its last minuet … the cracks never get pasted over.

I am looking for a better way to create a response document and I think a wiki could be it.

Instead of breaking it up into chunks the bid manager creates a frame work in a wiki, all the team members have visibility of the whole response all the time, they can make changes to any part of the doc.

Bada bing – you have your response doc at the end of the process. It then goes to a graphic designer so that the copy can be typeset.

This is better because

1 Ditch the baton method
Or the “you do your bit” method, which creates a culture of “ive done my bit” rather than “what’s next to-do?”

2 Visibility of everyone  else’s style
When working on the doc you will be able to see what has gone before, this is the first step on the road to getting the writing style in sync.

3 Abstraction of content from presentation

This is the biggest problem with the old word and powerpoint  tool set. Loads of effort is spent mucking round with tables, merging documents, getting the bullet formats right. Content authors should not be concerned with this, they should just say … here is bullet points … here is a diagram. The formatting should be done by the professional type setter, if the content is designed using a wiki then you can export to word/pdf etc and then apply formatting.

4 collaboration with the customer
If you have the response as a wiki, why not share it with your customer? They can make comments directly, they could even be involved in the design and editing process.

5 vitalizing the team

This style of collaboration tool is awesome when you have a virtual team, it will give you a real advantage over your competitors, you can bring people in and out of the fast, and you can get the most from them when they are there.

Integrating information systems in a corporation

Have you ever tried to get everyone using the same information system, are you wondering why its so hard?

This is why,

1. Different regions will refuse to use the corporate backed solution, for almost any reason they can find.
2. Different development groups will chose to hide their systems rather than spend time learning/migrating to the corporate solution, because they dont want to give up their indipendance
3. Systems that may have started as small information repositories will have organically grown, and had turned into business critical systems, to replace them with the corporate information solution is just too risky
4. Acquisition of new business will caused dilution as the new units existing information systems will be too expensive to change.
5. Multi language content (and character sets) will cause issues during migration leading to the previous system remaining in place.

Just like King Canute you cant hold back the tide. Give up and instead implement and publicise a search facility that provides a single place to go to find content rather than have a sing place to go to author content.

How to make the most of your enterprise wiki

Top tips and tricks for the for the new wiki user

So you’ve installed a wiki in your company and some people love it but other don’t … dont worry here are some tips and tricks to get you going.

1. You may wonder why people are not visiting your project or team wiki, use the news or blogging feature to keep people coming back.
2. Make it look great, make your wiki look better than the other ones at your company, If you can afford it hire a graphic designer to do it for you.
3. If you want to author content quickly ditch the rich text editor – use the wiki markup instead, its really easy and much faster.
4. If you want to bring a team together quickly – create a new wiki for them
5. Once you have a wiki for your team, create a blog, get some discussion going
6. If you see a page you like, open it, look at the markup and copy it
7. Use pictures to emphasise points
8. look on the web – there are literally millions of how to articles
9. If you cant do it then someone has made a plugin that will
10. Instead of emailing the content, send a link and ask for them to add comments to the page
11. Leave empty links in your content so that others can help fill out the content

remember, some people just dont like collaborative working … try and support them, but dont give in.

How to generate ideas

All you need is one piece of paper, your favorite cafe, a pencil and a lack of inhibitions

Often I am asked to think up a few ides on a specific topic, or to come up with a new architecture for a product.

This can be really difficult, especially when you have to get somthing quick. Here is one of the methods that I use to do this I call it an Ideas sheet.

The process is straight forward,

1. get out of the office … find a cafe, park, street corner any where that is comfortable that you are in control of any interuptions.
2. get a blank piece of paper,
3. Clear your mind for a while
4. Think about the essence of what is being asked for,
   who is it for?
   why is it fun?
   what is so great about it?
5. When you get an idea write it down on the paper, if words are too restrictive … then draw a picture.
6. Now try to completely forget the last idea, turn the page up side down so that you cant read it. or place another piece of paper on to of it.
7. Go back to thinking of the essence of the issue or what you want to make, when you get an idea .. repeat.
8. Now just keep going till the paper is full
9. If you spend more than an hour on this then give up, try again another day.

As you can see this often makes some funny ideas. Which are all good. When you come to discuss the ideas with your collegues they can all have a good laugh, which really helps with making the job fun.