Just got back from a stimulating evening meeting of the BCS SPA specialist group. The presenter was Emily Webber on Building Successful Communities of Practice. If I understood correctly, a community of practice is a cross-functional, self-selected group of practitioners doing roughly the same tasks in different teams, business units or even organisations. Spotify has identified almost the identical concept in its "guilds".
The big takeaway for me (apart from the fact that Emily in real life doesn't look nearly as similar to Sarah Millican as she does in her photo) was that the mutual support provided by such a group gives people more autonomy and more mastery of their craft, both of which are strong motivating factors and promote happiness, which in turn results in demonstrably higher productivity and lower staff turnover (a study by Warwick University showed the productivity of happy employees to be 10-12% higher than average, while that of unhappy ones was 10% or more below). This would seem to suggest that allowing as much as one day a week to employees to exchange ideas and experiment with ways to improve their technique could be a worthwhile investment.
Showing posts with label software practice. Show all posts
Showing posts with label software practice. Show all posts
Wednesday, 4 May 2016
Sunday, 19 June 2011
Inspiring the next generation of developers
Jason Gorman has published a thought-provoking opinion piece asking why schools are doing so little to promote IT as an enticing career option and to equip kids to take advantage of it. His analysis points to a lack of suitably qualified teachers (so what's new?) and a commensurate lack of ambition on the part of exam boards to make the syllabus industry-relevant.
Do get in touch with Jason to take part in a summit at Bletchley Park (where else?) on 25th August 2011 to identify practical measures that can be taken to improve this dire situation.
I think this is an issue the BCS should be addressing with all dispatch instead of tying itself in knots over some elusive ideal of making all IT practitioners professionally qualified. Some of the most proficient software practitioners I know have no professional qualifications at all.
Do get in touch with Jason to take part in a summit at Bletchley Park (where else?) on 25th August 2011 to identify practical measures that can be taken to improve this dire situation.
I think this is an issue the BCS should be addressing with all dispatch instead of tying itself in knots over some elusive ideal of making all IT practitioners professionally qualified. Some of the most proficient software practitioners I know have no professional qualifications at all.
Wednesday, 12 January 2011
Software: Craft or Trade? You decide
Dan North has started a serious discussion with his insightful article about the Software Craftsmanship movement and where its manifesto possibly misses the point.
Thursday, 6 January 2011
Breaking up the big rocks
A colleague has circulated Richard Lawrence's nine patterns for dividing up user stories. These are going to be very useful. I wonder if someone will add more to make the magic Baker's Dozen?
New Ideas in Social Marketing
Attended a stunning event last night at the BCS London conference rooms. The speakers were Thomas Power of Ecademy and Lee Bryant of Headshift. The event was jointly organised by Richard Tandoh, Dalim Basu and Sara Misell on behalf of the North London Branch, Elayne Coakes on behalf of the BCS Sociotechnical specialist group and me on behalf of BCS Software Practice Advancement.
I learned that my use of social media was probably at the very raw beginner level - and moreover, that all the companies I have ever worked for, including my current employer, are at or below that level. If you want some insights into your level of influence measured by the effectiveness of your online behaviour (and how it compares to others), try Klout or PeerIndex. These applications use people's Twitter usernames as the primary key, so if you aren't on Twitter, you don't even get to first base.
Thomas showed how the stream of information we receive from the Web is growing exponentially - his FriendFeed home page was updating with new events more than once a second. A potentially incredibly useful tool for cutting this deluge down to size is made by My6Sense. They make a reader for iPhone, iPod Touch and Android devices that watches your Twitter, Facebook, News and RSS streams and brings the most important items to your attention. Thomas believes it takes around 30 hours to train it. More importantly, this being a social media world, once something has caught your attention, the my6sense app lets you share it easily with your own network of contacts.
In the Q&A session, I found out about a recently launched online service that is attempting to cross-fertilise a crowd-sourced knowledge repository (think Wikipedia) with a personal reputation index (like eBranding Me). A fun way to find out more is to take the Quora programming challenge.
The discussion in the pub afterwards was most illuminating too, though it veered away from social media to discussing the disaster that is likely to befall the civilised world when, not if, the next massive Coronal Mass Ejection occurs. This event is expected to occur within 10-24 months as of this writing and is likely to knock out not only communications networks (particularly satellite-based ones) but all manner of computer systems, data networks and power grids. Since everything these days is dependent on computers, we're likely to suffer supply shortages of everything from drinking water to fuel. As for withdrawing money from your bank account, you will probably be well advised to forget it for a few months. The guy telling us this has inside knowledge as a result of working for a major data security company and claims that they have working solutions to sell that will handle the backup and disaster recovery requirements of computer users from home users to data centres (remember that from the first detection of a CME, the world has only 15 minutes to secure everything before the plasma storm hits). His advice is to print out your bank statements and keep them safe along with non-perishable emergency supplies; also to have a spare laptop computer somewhere wrapped in several layers of tin foil to protect it from EMP. Contact me if you want to know more!
I learned that my use of social media was probably at the very raw beginner level - and moreover, that all the companies I have ever worked for, including my current employer, are at or below that level. If you want some insights into your level of influence measured by the effectiveness of your online behaviour (and how it compares to others), try Klout or PeerIndex. These applications use people's Twitter usernames as the primary key, so if you aren't on Twitter, you don't even get to first base.
Thomas showed how the stream of information we receive from the Web is growing exponentially - his FriendFeed home page was updating with new events more than once a second. A potentially incredibly useful tool for cutting this deluge down to size is made by My6Sense. They make a reader for iPhone, iPod Touch and Android devices that watches your Twitter, Facebook, News and RSS streams and brings the most important items to your attention. Thomas believes it takes around 30 hours to train it. More importantly, this being a social media world, once something has caught your attention, the my6sense app lets you share it easily with your own network of contacts.
In the Q&A session, I found out about a recently launched online service that is attempting to cross-fertilise a crowd-sourced knowledge repository (think Wikipedia) with a personal reputation index (like eBranding Me). A fun way to find out more is to take the Quora programming challenge.
The discussion in the pub afterwards was most illuminating too, though it veered away from social media to discussing the disaster that is likely to befall the civilised world when, not if, the next massive Coronal Mass Ejection occurs. This event is expected to occur within 10-24 months as of this writing and is likely to knock out not only communications networks (particularly satellite-based ones) but all manner of computer systems, data networks and power grids. Since everything these days is dependent on computers, we're likely to suffer supply shortages of everything from drinking water to fuel. As for withdrawing money from your bank account, you will probably be well advised to forget it for a few months. The guy telling us this has inside knowledge as a result of working for a major data security company and claims that they have working solutions to sell that will handle the backup and disaster recovery requirements of computer users from home users to data centres (remember that from the first detection of a CME, the world has only 15 minutes to secure everything before the plasma storm hits). His advice is to print out your bank statements and keep them safe along with non-perishable emergency supplies; also to have a spare laptop computer somewhere wrapped in several layers of tin foil to protect it from EMP. Contact me if you want to know more!
Wednesday, 19 May 2010
BCS SPA2010 conference
Final day of the conference - it's gone much too quickly as usual. My favourite session to date has been the brief whirlwind tour of agile practices given by Gwyn Morfey and Laurie Young of New Bamboo - "the Sword of Integration". This was a highly interactive session that involved everyone standing up and moving about enthusiastically, which despite the cramped room, meant that we all ended up remembering something instantly useful from the session.
By the way, the sword of integration itself is just one example of an instant solution to a pressing problem. The situation was that multiple developers checking in their changes would cause each other to have merge conflicts. The solution: a paper "sword" quickly assembled, which when held conferred on the holder the right to check in - and hit anyone who checked in when they shouldn't. The principle being illustrated is "just try it" - there is no need to get it absolutely right first time. If it doesn't work, we can change it later.
By the way, the sword of integration itself is just one example of an instant solution to a pressing problem. The situation was that multiple developers checking in their changes would cause each other to have merge conflicts. The solution: a paper "sword" quickly assembled, which when held conferred on the holder the right to check in - and hit anyone who checked in when they shouldn't. The principle being illustrated is "just try it" - there is no need to get it absolutely right first time. If it doesn't work, we can change it later.
Wednesday, 13 January 2010
Craftsmanship for Teams
Very interesting discussion thread on Software Craftsmanship as a team exercise. In response to Cory Foy's posting, Steven Smith makes an interesting analogy with coaching a sports team and says how that is actually carried through in his practice.
Monday, 15 June 2009
Test-Driven Design is not testing
I've recently worked with a team doing its first agile project (though one or two team members had been involved in an agile project before). The most difficult concept to get across was TDD - test driven design. I found that people really didn't grok the idea until I pair-programmed with them for a couple of hours. I wonder why that might be.
Dan North has suggested one possibility. He observed that newcomers to TDD often don't get the really big payback because they continue to think that TDD is mainly about testing - even if they will admit that writing the tests before the code leads to better quality code. They never transition to treating TDD as a design process, letting them discover the API to a component they're writing, nor to the realisation that TDD is about defining the behaviour of their component and its interactions with other components of the system.
Keith Braithwaite has put forward another consideration. In physical engineering disciplines, practitioners speed up their work process by using gauges. There are many kinds, from the simple spark plug gap gauge, which is simply a sliver of metal to slide between the electrodes, to electronic vernier calliper gauges that can be pre-set to a precise dimension with tolerances above and below. Each workpiece is tested at each stage of the process by checking its dimensions with the appropriate gauge(s). Workpieces that are out of tolerance are sent back for rework or scrapped. Our unit tests are a bit like that - they provide a safeguard that the software component we're working on still meets all its requirements following any engineering we've done.
It occurred to me today that unit and acceptance tests, particularly if automated, perform another valuable function in the context of an agile (especially a lean) development process. Whereas the waterfall processes familiar to most developers are characterised by "quality gates" at key stages, every single artifact in an agile development has its own little quality gate, manifested in the appropriate tests. This theoretically frees the development process from the usual bottlenecks that the quality gates tend to become.
I say "theoretically", because in many instances agile development projects have to take place within a quality system that doesn't take advantage of incremental delivery. Instead, continued approval and in many cases funding for the project tends to be contingent on passing the traditional quality gates following requirements analysis, functional specification, high-level design, low-level design, coding, integration, system test and acceptance. Project managers are therefore forced to conjure up some kind of spurious linkage between the milestones laid down in the rigid quality system and some arbitrary points along their product release plan. This can hamper their freedom to adjust the release plan in response to changing circumstances and emerging technical insights.
This could be avoided if the quality system could recognise that properly written tests represent every work product of a software development project apart from the code itself. It should therefore simply insist on a verification at each iteration (or at each release, perhaps) that the tests comprehensively and comprehensibly represent the requirements of the business on the system under development and that the required set of tests pass repeatably. I say "the required set" because there's always the possibility that some tests will intentionally fail - e.g. where they have been written to test features that are not yet in the current release.
In other words, TDD can be used to eliminate the quality-gate bottlenecks of quality systems that assume waterfall development processes.
Dan North has suggested one possibility. He observed that newcomers to TDD often don't get the really big payback because they continue to think that TDD is mainly about testing - even if they will admit that writing the tests before the code leads to better quality code. They never transition to treating TDD as a design process, letting them discover the API to a component they're writing, nor to the realisation that TDD is about defining the behaviour of their component and its interactions with other components of the system.
Keith Braithwaite has put forward another consideration. In physical engineering disciplines, practitioners speed up their work process by using gauges. There are many kinds, from the simple spark plug gap gauge, which is simply a sliver of metal to slide between the electrodes, to electronic vernier calliper gauges that can be pre-set to a precise dimension with tolerances above and below. Each workpiece is tested at each stage of the process by checking its dimensions with the appropriate gauge(s). Workpieces that are out of tolerance are sent back for rework or scrapped. Our unit tests are a bit like that - they provide a safeguard that the software component we're working on still meets all its requirements following any engineering we've done.
It occurred to me today that unit and acceptance tests, particularly if automated, perform another valuable function in the context of an agile (especially a lean) development process. Whereas the waterfall processes familiar to most developers are characterised by "quality gates" at key stages, every single artifact in an agile development has its own little quality gate, manifested in the appropriate tests. This theoretically frees the development process from the usual bottlenecks that the quality gates tend to become.
I say "theoretically", because in many instances agile development projects have to take place within a quality system that doesn't take advantage of incremental delivery. Instead, continued approval and in many cases funding for the project tends to be contingent on passing the traditional quality gates following requirements analysis, functional specification, high-level design, low-level design, coding, integration, system test and acceptance. Project managers are therefore forced to conjure up some kind of spurious linkage between the milestones laid down in the rigid quality system and some arbitrary points along their product release plan. This can hamper their freedom to adjust the release plan in response to changing circumstances and emerging technical insights.
This could be avoided if the quality system could recognise that properly written tests represent every work product of a software development project apart from the code itself. It should therefore simply insist on a verification at each iteration (or at each release, perhaps) that the tests comprehensively and comprehensibly represent the requirements of the business on the system under development and that the required set of tests pass repeatably. I say "the required set" because there's always the possibility that some tests will intentionally fail - e.g. where they have been written to test features that are not yet in the current release.
In other words, TDD can be used to eliminate the quality-gate bottlenecks of quality systems that assume waterfall development processes.
Friday, 15 May 2009
24th March 2009: Theory of Constraints Challenged
My sincere thanks to Kevin Rutherford and Allan Kelly for co-presenting a fascinating session about lean software development to the BCS Kingston & Croydon branch on 24th March this year, entitled "Lean, Constraints, Action!". The audience was excellent too and helped us re-create a famous experiment related by Eliyahu Goldratt in "The Goal".
(Click images to see a larger version)
I had participated in this game previously at the London XP Day 2008 (facilitated by Karl Scotland in an Open Space session). It is designed to demonstrate an intuitively paradoxical finding: that a lean, pull-oriented flow substantially reduces the amount of inventory or work in progress (WIP), while improving throughput.
However, I had a sneaky feeling that the experiment was biased, because in the first "push" simulation, the assembly line was not pre-loaded with WIP, while in the second "pull" simulation, the line was pre-loaded with workpieces at each "workstation's" input buffer up to either the maximum limit or to 50% of that limit. Therefore in a simulation of 10 rounds (equivalent to ten working days - approximately equal to the average cycle time in a six-workstation setup) the push simulation will only start to produce output towards the very end of the simulation, while the pull simulation will produce something from the very first day.
So I got Allan and Kevin to agree to vary the rules a little bit, to try to get closer to a "steady state" from the first "day". Before each of the two simulations, our teams placed three Lego blocks on each of the coasters representing the input buffers of the second through sixth workstations (the first workstation of course has the whole of the product backlog as its input hopper). In fact, as it turned out, four workpieces would have been closer to the true steady state in the pull simulation, even more in the push simulation.
Off our teams went and played the production line for ten rounds each. In the push simulation, the die was passed in order from workstation 1 to workstation 6 during each round and the number of workpieces transferred to the next input buffer was the number thrown, up to the number of pieces available in the workstation's input buffer. Instances of starvation were rare under this system, but did occur sometimes. At the end we counted up the number of pieces that had come off the end of the line and the number currently in progress (i.e. on any of the five input buffers for workstations 2 to 6).
In the pull simulation, the die was passed in the opposite direction and the input buffers were constrained to a maximum of six workpieces. So if the next input buffer had three pieces already in it and the player threw anything over a 3, they could only pass along 3 more workpieces (subject to their own input buffer holding at least 3, of course). Once again, the results after 10 rounds were compared.
The results didn't surprise me particularly, but I think some of the others were a little taken aback:
As you can see, the constraint resulted in both lower WIP and lower throughput. This makes sense when you consider that there were far more occasions during the pull game than during the push game when players were unable to process the full number of workpieces indicated by the die.
Looking back at the game notes, it is noted that if the simulation is run for much longer than 10 days, the pull (or Kanban) system "will rarely produce as much as the traditional push". This may have escaped the attention of some readers (or perhaps it's a more recent edit - I don't know).
My conclusion is that you get nothing for free. The cost of reducing WIP is reduced throughput, which is perfectly acceptable as long as you're aware of it. Software development projects are not production lines in any case, so it is very unlikely that any developer will sit around kicking her or his heels if the work runs out on a given day. There are always low priority tasks such as fettling the build system, cleaning up the documentation on the project Wiki, answering user support requests etc. - or just take the next item off the product backlog and raise the kanban limit temporarily.
(Click images to see a larger version)
I had participated in this game previously at the London XP Day 2008 (facilitated by Karl Scotland in an Open Space session). It is designed to demonstrate an intuitively paradoxical finding: that a lean, pull-oriented flow substantially reduces the amount of inventory or work in progress (WIP), while improving throughput.
However, I had a sneaky feeling that the experiment was biased, because in the first "push" simulation, the assembly line was not pre-loaded with WIP, while in the second "pull" simulation, the line was pre-loaded with workpieces at each "workstation's" input buffer up to either the maximum limit or to 50% of that limit. Therefore in a simulation of 10 rounds (equivalent to ten working days - approximately equal to the average cycle time in a six-workstation setup) the push simulation will only start to produce output towards the very end of the simulation, while the pull simulation will produce something from the very first day.
So I got Allan and Kevin to agree to vary the rules a little bit, to try to get closer to a "steady state" from the first "day". Before each of the two simulations, our teams placed three Lego blocks on each of the coasters representing the input buffers of the second through sixth workstations (the first workstation of course has the whole of the product backlog as its input hopper). In fact, as it turned out, four workpieces would have been closer to the true steady state in the pull simulation, even more in the push simulation.
Off our teams went and played the production line for ten rounds each. In the push simulation, the die was passed in order from workstation 1 to workstation 6 during each round and the number of workpieces transferred to the next input buffer was the number thrown, up to the number of pieces available in the workstation's input buffer. Instances of starvation were rare under this system, but did occur sometimes. At the end we counted up the number of pieces that had come off the end of the line and the number currently in progress (i.e. on any of the five input buffers for workstations 2 to 6).
In the pull simulation, the die was passed in the opposite direction and the input buffers were constrained to a maximum of six workpieces. So if the next input buffer had three pieces already in it and the player threw anything over a 3, they could only pass along 3 more workpieces (subject to their own input buffer holding at least 3, of course). Once again, the results after 10 rounds were compared.
The results didn't surprise me particularly, but I think some of the others were a little taken aback:
As you can see, the constraint resulted in both lower WIP and lower throughput. This makes sense when you consider that there were far more occasions during the pull game than during the push game when players were unable to process the full number of workpieces indicated by the die.
Looking back at the game notes, it is noted that if the simulation is run for much longer than 10 days, the pull (or Kanban) system "will rarely produce as much as the traditional push". This may have escaped the attention of some readers (or perhaps it's a more recent edit - I don't know).
My conclusion is that you get nothing for free. The cost of reducing WIP is reduced throughput, which is perfectly acceptable as long as you're aware of it. Software development projects are not production lines in any case, so it is very unlikely that any developer will sit around kicking her or his heels if the work runs out on a given day. There are always low priority tasks such as fettling the build system, cleaning up the documentation on the project Wiki, answering user support requests etc. - or just take the next item off the product backlog and raise the kanban limit temporarily.
Tuesday, 5 May 2009
Distributed bug-tracking in Haskell
At the recent SPA 2009 conference, there was a lot of talk about functional programming, Haskell in particular (a couple of years ago, the flavour of the month had been Erlang). Just to prove that Haskell is no longer "just a research language", along comes DisTract, a distributed issue-tracking system that runs in Firefox browsers. If you're already using Git, Darcs, Mercurial or Monotone as your distributed software configuration management solution, the author reasoned, why shouldn't you be able to close bugs while you're off-line at the same time as you check in your fix? Caveat: I have not tried this yet, but it sounds like a really neat idea. Does anyone know of a user forum?
Thursday, 9 April 2009
SPA2009 - first impressions
Maybe I'm biased, of course, but for me the SPA2009 conference felt even better than last year's. I think it had the right mix of technical and non-technical sessions, mostly of very high quality, and a few really interesting BOF (birds of a feather) sessions - which for once, didn't feel as if they were just squeezed in at the last minute.
Functional programming (in particular, Haskell) was a major theme this year, as was testing. My eyes were opened to the possibility of doing test-driven development (TDD) in Haskell - in fact, functional languages are better at this than imperative (stateful) languages. It was also good to meet up with a lot of familiar faces at the joint XtC meeting on the Tuesday night.
My session notes are on my other laptop. I will try to post them on the SPA SG site over the Easter weekend, other duties permitting.
Functional programming (in particular, Haskell) was a major theme this year, as was testing. My eyes were opened to the possibility of doing test-driven development (TDD) in Haskell - in fact, functional languages are better at this than imperative (stateful) languages. It was also good to meet up with a lot of familiar faces at the joint XtC meeting on the Tuesday night.
My session notes are on my other laptop. I will try to post them on the SPA SG site over the Easter weekend, other duties permitting.
Tuesday, 17 March 2009
Tools to support agile methods
The whole point of managing a project using an agile method is to use lots of coloured cards and post-it notes, but sometimes you have to fall back on a boring old software tool. The thorny question keeps arising: which one do I recommend?
Many different project management tools exist, at different price-points and levels of functionality. A long list is shown below. It is important to be clear about a project's requirements for a tool before selecting. Avoid the temptation to extend any tool you select or to spend much effort integrating it with the rest of your project environment – this is a sure way to lock yourself into a single supplier.
The following list of tools is not exhaustive, though I have kept adding to it as I came across new tools:
A number of web sites compare small subsets of the available software tools, including
Many different project management tools exist, at different price-points and levels of functionality. A long list is shown below. It is important to be clear about a project's requirements for a tool before selecting. Avoid the temptation to extend any tool you select or to spend much effort integrating it with the rest of your project environment – this is a sure way to lock yourself into a single supplier.
The following list of tools is not exhaustive, though I have kept adding to it as I came across new tools:
- ]project-open[
- Achievo
- ActiveCollab
- Agilebuddy - reported by a comment on this post to be a full-featured agile project management software tool, which is easy to use and great for Scrum teams. Offered on a subscription model for US$9.95 per user per month
- Agilefant
- Agilo – based on the Trac issue-management tool and said to support only a single project at a time
- airTODO – PMBOK rather than agile, but minimalist (an Eclipse plug-in)
- AxoSoft's OnTime - available as a hosted cloud solution, a Windows native application or as a web application, one comment under this post has reported that it "great for agile / scrum development". Comparable in scope to Trac, but looks a lot more snazzy
- Banana Scrum - according to one comment below, this is a nice, web based tool that helps without getting in team's way
- Extreme Planner
- Greenhopper – a JIRA plugin favoured by some Scrum teams
- IceScrum
- Mingle - provides a shared workspace for agile teams, supporting XP, Scrum and custom hybrid approaches. Includes a virtual card wall, wiki, charts, reports and more. Integrated with issue tracking and continuous build. Priced US$995 per user with substantial discounts for multiple licences, academic institutions etc.
- Pivotal Tracker
- ProjectCards – mixed approach that uses both physical cards and software
- ProjectKoach
- Rally
- Rational Team Concert - integrates work item, continuous integration builds and software configuration management (SCM) on the collaborative infrastructure of the Jazz Team Server
- redMine
- Scrum Edge - someone commented below that it was much simpler to use than most other Scrum tools
- Scrumworks - quite popular free open source package, heavily forms-based, can integrate with JIRA
- Silver Catalyst
- StuffPlanner – Zühlke's inhouse-developed browser-based tool now at version 0.1 and with an Eclipse Mylyn connector available; access can be provided by arrangement
- TargetProcess - designed to support Scrum, XP and custom Agile processes particularly in the .NET environment. Includes a comprehensive set of tools and features, including defect-tracking, test management and customer helpdesk portal. Community edition free for up to 5 users
- teamwork
- tinyPM
- VersionOne - very full-featured, supports Scrum, DSDM, XP and AUP across multiple projects. Priced from US$348 per user per year, there is a free "team edition" for one team of up to 10
- XP Story Studio – no development since 2004
- XPlanner - a popular free open source planning and tracking tool for XP. Quite simple in keeping with the low-ceremony agile approach
- xProcess - free open source project management and process improvement tool, focused particularly on agile and priority-driven approaches. Preconfigured processes include Scrum, FDD, Prince2, Unified and others; can be tailored. Gantt/Burndowns/target status continuously updated. See also xProcess Europe
- XPWeb
A number of web sites compare small subsets of the available software tools, including
Thursday, 26 February 2009
My Favourite Keyboard Shortcuts
That was the title of a session I proposed for today's first-ever Software Craftsmanship Conference, at the BBC's attractive Media Centre in London's White City. To my surprise, the session was accepted. It worked quite well despite attracting only about half a dozen participants. I certainly learned a good deal from it!
The output of the session has been posted on the conference Wiki. However, you'll have to be logged in to see it, as the wiki is private to conference participants. I don't know if Jason Gorman plans to change this now the conference is over.
The top tips (as a result of a quick spot vote at the end) were:
The three-step refactoring tango: Jason's recipe for method extraction where one or more parameters are themselves method calls. In Eclipse, it goes ALT-SHIFT-L (extract local variable), ALT-SHIFT-M (extract method), then ALT-SHIFT-I (inline local variable as method parameter).
Expand/shrink current selection: In Eclipse, ALT-SHIFT-up/down arrow or in IDEA, CTRL-w/W. With the cursor on a given word, the word is selected. Repeated applications of the same keyboard combo selects progressively larger portions of the source file (up to and including the entire file). Using the opposite key combination reduces the size of the selection all the way back to 0.
The output of the session has been posted on the conference Wiki. However, you'll have to be logged in to see it, as the wiki is private to conference participants. I don't know if Jason Gorman plans to change this now the conference is over.
The top tips (as a result of a quick spot vote at the end) were:
The three-step refactoring tango: Jason's recipe for method extraction where one or more parameters are themselves method calls. In Eclipse, it goes ALT-SHIFT-L (extract local variable), ALT-SHIFT-M (extract method), then ALT-SHIFT-I (inline local variable as method parameter).
Expand/shrink current selection: In Eclipse, ALT-SHIFT-up/down arrow or in IDEA, CTRL-w/W. With the cursor on a given word, the word is selected. Repeated applications of the same keyboard combo selects progressively larger portions of the source file (up to and including the entire file). Using the opposite key combination reduces the size of the selection all the way back to 0.
Tuesday, 17 February 2009
Agile and Lean - complementary or conflicting?
Dave West has contributed an article entitled A Marriage Made in Heaven?. I found it very instructive to read that as well as the comments attached to it. To my mind, there are things that the software community can learn (and has learned) from lean manufacturing, but in many respects software development is much more of a joint creative act. As Dave says, Peter Naur as long ago as 1985 equated programming with collaborative theory-building - in other words, it has much in common with research at the forefront of physics or mathematics, where results are difficult to predict and effort is almost impossible to forecast.
Tuesday, 14 October 2008
Improving team dynamics
Interested in making your team more effective? I found the following list of useful links just now after reconnecting to a former colleague on Plaxo Pulse.
And of course, my own company Zühlke Engineering offers tools, coaching and training to agile teams.
And of course, my own company Zühlke Engineering offers tools, coaching and training to agile teams.
Wednesday, 16 July 2008
Software Practice - The State of the Art
The British Computer Society's specialist group for Software Practice Advancement is staging a series of talks entitled The State of the Art. This features five talks from six of the leading experts in their respective fields, ranging from architecture to team dynamics.
It's excellent value at just £90 plus VAT - discounted to just £75 plus VAT for members of the specialist group or of the BCS generally. Numbers are limited, so book soon!
It's excellent value at just £90 plus VAT - discounted to just £75 plus VAT for members of the specialist group or of the BCS generally. Numbers are limited, so book soon!
Subscribe to:
Posts (Atom)
