Points of note or issues which are or appear to be important
Monday, April 13, 2009
Web Security - an eyeopener
The session used the Paros proxy server with Firefox which easily showed the web transactions when entering a simple URL (I won't disclose the URLs used in the demonstration, suffice to say that the sites were well-known). Using Paros, it is easy to see how much information is passed via cookies. Stopping cookies results in the same information being passed via URL (although this is more obvious since the data appears in some form in the address bar). In many cases the same data is passed to a number if websites regardless of whether the data is appropriate or useful to the receiving website.
Although it is possible to see the information being sent to a website, it is not possible to determine what is done with the data by the receiving site. In most cases the data is used to trace a journey through website (so that the 'user experience' can be improved) which is totally transparent to the user since these are performed server side.
So is it possible to stop the information being transferred? Not easily, but choose your sites carefully. There is some legislation in the EU which has tightened up the exchange of information through websites, particulalry to third parties, without the express permission of the user. Unfortunatley this legislation is dependent on where the website is hosted, which isn't always obvious from a simple URL. There is always 'education' which applies to both the end user and also to the developers of the site, and there are some good courses now which can help (e.g. ethical hacking and MSc in Information Security at Royal Holloway College in London) increase awareness.
Thursday, April 9, 2009
Can you scrum on your own?
Peter identified a couple of scenarios where he felt that 'Solo Scrum' could be appropriate:
- A full time developer doing open source development part-time
- A solo consultant developing applications for non-technical clients
- A 'work at home' contractor managing multiple clients
The traditional problems of planning don't go away when working on your own (as I said at the session 'Fail to plan, plan to fail'). Working on your own necessitates an efficient process for planning and managing the plan (a bit more than the 'back of an envelope' note). There are a number of Eclipse plugins (e.g. mylyn) which offer the right balance in terms of monitoring the work activity without distracting from the task-at-hand.
Some interesting ideas were discussed, including the observation that many team collaboration software packages often includes a free version for a small team (where small can be up to 5). This can overcome a often heard comment which was that I don't have the time/experience/etc to set up a 'professional' development environment (the minimum being a source control system, an IDE and a bug tracking system) from scratch.
Peter has now started a Google group to further the debate. I will watch with interest.
SPA2009
Having attended last year's conference and thoroughly enjoyed it, I was disappointed that my work commitments meant that I could only attend a single day of this year's conference. Attending a single day meant that I was keen to catch as much of the buzz as possible as well as catching up with some friends. I managed to attend 2 sessions, on AJAX web testing using Selenium and Solo Scrum, together with 2 BoF sessions on Web security (or lack of it) and Lean/Kanban in a stimulating day. I will summarise my notes over the next few days.
Friday, March 20, 2009
Case Studies in Enterprise Architecture
A few nights ago, I attended a fascinating evening with Wayne Horkan, the CTO of Sun Microsystems for UK and Ireland, who presented his views on Enterprise Architecture. The event was jointly organised by IET, the BCS Manchester branch with a pitch for the recently formed BCS Enterprise Architecture Specialist Group forming the warm act before Wayne's presentation.
Wayne presented his experience in 3 (anonymous) organisations who experienced difficulties in their approach to delivering an enterprise architecture. The problems could easily be addressed by recognising the key and important role of enterprise architects who maintain an understanding of the business context, provides domain knowledge and ensure that the architecture and supporting IT remains aligned with the business.
In assessing any programme, a simple 4 stage approach is followed:
- Gather the facts by a series of interviews and information gathering. This includes understanding the current 'as is' enterprise architecture, the current IT/IS setup and the 'vision' for the future.
- Analyse the data
- Determine the key conclusions/recommendations and the way foward. This includes establishing the order of change to ensure that the changes deliver value to the organisation without destablising the exsiting organisation.
- Assess the project against the five key areas of likely project failure:
- Strategy. Is it really needed? Why is it needed now? Will it deliver a realistic ROI?
- Contractual. Is the contract, including the financial elements, appropriate defined and achievable?
- Process/procedures. Are we in control or out of control?
- Politics and personnel. Is there buy-in from all concerned/affected?
- Technical and architectural. The least likely cause of project failure (apparently) but need to ensure that the right resources are available in order to deliver the right solution.
Wayne concluded with a number of best practices based on his experiences with these (and other) organisations:
Ignore the religious arguments about which framework to use. Just pick a single framework and stick with it. Most organisations use a blend of Zachman (artefact focused) and TOGAF (procedurally focused). None of the frameworks provide a magic bullet with which success is guaranteed.
Obtain sponsorship from key stakeholders. The stakeholders must have a strategy for the business, which may change over time, that is communicated to the EA team.
The EA team must continually:
Remain delivery focused, providing value to the organisation
Involve the whole team (consisting of Enterprise, Infrastructure and Application architects) in all decisions, ensuring that cross-team communication is integral to the team (no silos)
Ensure that there is the right mix of technical skills to deliver the right architecture
Obtain and foster Sponsorship, Sponsorship, Sponsorship without which a programme is likely to fail
Keep aligned (and checking) with the business strategy
As a reality check, Wayne highlighted that the current economic climate now requires that the investment in enterprise architecture must be seen to deliver value far more quickly (i.e. in the matter of months rather than years) to the business than has previously been tolerated.
The session was well attended and left the audience with much to consider in future projects.
The slides, and Wayne's personal views on the session are contained here.
Sunday, March 1, 2009
Going forward with PHP
http://finance.yahoo.com/d/quotes.csv?f=l1d2c1p2&s='.$stock_symbol
function get_share_price($stock_symbol){$url="http://finance.yahoo.com/d/quotes.csv?f=l1t1d1c1p&s=".$stock_symbol;$filesize = 2000;$handle = fopen($url, "r");$arr = fgetcsv($handle , $filesize , ',');fclose($handle);return $arr;}
- array_reverse -to reverse an array (required because the Yahoo data is returned with the most recent data first)
- array_slice -to take a subset of an array
- min, max - to determine the minimum and maximum values (how many times has code for this suimple function been written!)
Tuesday, October 14, 2008
The Power of the Door
It made me think about my experiences on numerous development projects and I would tend to agree with the recommendations outlined in the presentation. I remember when I was working long hours AND studying for a post-graduate degree trying to write some very simple Eiffel code and failing to get it work after 2 hours of staring at a simple logic problem. I simply couldn't solve it at the end of a 15 hour working day. I went home and came back a few days later, refreshed. I solved the problem in 5 minutes. The lesson was clear to me then - you need sleep, not heroes. This was admirably demonstrated in an overnight session to get a demo working and after 8 hours through the night of being in a no better situation than we were when we started!.
As organisations have changed over the years, office space has become at a premium. The 'power of the door' was demonstrated when I was a young engineer doing a major retargetting exercise. I remember we had to convince our manager of the benefit of having our own server to work on this exercise - he agreed provided we could reduce the schedule by 6 months. This we did easily, not just because of having our own server but because we had a large wooden door on our small team office. If it was shut (which it was normally) people just walked past so you didn't get disturbed. I would guess that if we reverted back to small offices, the software industry would be much more productive than it is today. I wonder how many project managers have the power or insight to challenge the office environment and make the necessary changes that will increase the chance of project success and increase team morale.
Thursday, September 11, 2008
The role of Project Managers in Agile Projects
I recently attended Allan Kelly's presentation on 'Why and How to Become Agile', an event organised by the BCS Project Management Specialist Group. As you would expect from an experienced agile practitioner, Allan provided a good overview of what agile was and why he considered agile to be better.
However, given that the audience was mainly project managers of one sort or another, I was interested in his statements on the role of project managers in agile developments. Mainstream agile methods such as XP, SCRUM or Crystal are very silent about the role of the Project Manager. This doesn't mean that they can be dispensed with, it is just that the various agile developments concentrate on the approach to improving business value with a development rather than the associated management tasks. I know agile promotes self-organising teams (in my experience this is removing a hierarchy of developers, architects and testers) but I know of few organisations that don't allocate a project manager to a development project however small. I therefore advocate that the project manager role remains as critical as ever although the scope of some of his tasks may change.
Regardless of the development approach, all projects need to manage risk, budgets, communications and resources (physical and people). The classic management approach is for these tasks to be allocated to a (often dedicated) project manager so that the workers can get on with serious development work. I don't think there is any need for this approach to significantly change. One task which Allan indicated would change for the project manager was planning as the emphaisis on planning changes in agile developments to be much less formal. This may be appropriate for (small) purely software development projects but the vast majority of projects are multi-disciplined in which the dependencies between the various activities need to be accepted and understood by all parties regardless of the formality of capturing this information. The project manager's role still remains an important factor in the eventual success of the project and the choice of project manager is probably more important than ever. In my experience the best project managers for developments adopting some agile practices are those who are hands-on, are developers who have experienced agile first-hand, understand the project and are empowered to make decisions. It is the last point which mustn't be under-estimated; delays in decision making processes are classic signs of a development that is struggling and agile developments can't afford unnecessary delays.
I note that the latest DSDM version (Atern) now explicitly includes the role of a Project Leader (you can even get a qualification). Does this now recognise that the classic project manager now needs to more formally recognised in agile developments? I would probably say no; it is probably more a reflection on the type of organisations using DSDM who feel comfortable with an explicit role being defined rather a comment on the management of agile developments in general.
Now that agile development approaches have become more accepted as a 'normal' way of performing software developments, it is probably true to say that the role of the project manager has survived relatively intact. However the project manager now has a key role in being much more involved with the development rather than performing a purely managerial overview role; but this is what the best project managers have always done.