Wednesday, December 22, 2010

top-50-programming-quotes-of-all-time

http://www.junauza.com/2010/12/top-50-programming-quotes-of-all-time.html

Tuesday, December 7, 2010

Mythical Man Month

http://www.comp.mq.edu.au/units/comp340/public/mythical.pdf

http://www.cs.virginia.edu/~twh5b/quals/presentations/The%20Mythical%20Man-Month.pdf

http://www.infoq.com/articles/brooks-design-book-review

http://blog.assembla.com/assemblablog/tabid/12618/bid/6213/Time-to-Vanquish-the-Mythical-Man-Month.aspx

Harlan Mills Proposal

http://www.comp.mq.edu.au/units/comp340/public/mythical.pdf

Harlan Mills Proposal

Each segment of a large project be undertaken by a team

Team organised like a surgical team with specific roles
One “surgeon” doing the butchery; everyone else in support
Few minds involved in design
Highly segmented/independent tasks
Minimal communication during operations; only ever 1-1

The Roles

Surgeon

Chief programmer
Defines all functional and non-functional specifications
Designs, codes and tests program, writes doco
Very experienced, very talented person
Considerable applications and systems knowledge in relevant field
Uses computer system to implement and test the code directly

Copilot
– Backup for the surgeon
– Can do everything the surgeon does
– But has less experience
– Shares in design as a thinker, discussant and evaluator
– Surgeon tries out ideas on her, but doesn’t have to accept advice
– Copilot communicates with team; relays advice to surgeon
– Knows all code intimately; researches alternative designs
– Bus accident insurance
– May write code but not responsible for it
Administrator
– Surgeon is the boss…BUT must spend no time dealing with personnel, space, money, machines, bureaucracy
– This is the role of the administrator
– Liaises with stakeholders
– May be full-time if significant legal, contractual, reporting requirements
– One administrator may serve multiple teams
Editor
– Responsible for writing doco
– Generates external and internal descriptions
– Takes draft provided by surgeon and refines, clarifies, amplifies
– Criticises and reworks
– Manages versioning
– Inserts references and bibliographies
– Responsible for production and publication
Two Secretaries
– Surgeon and administrator both have a secretary
– Deal with correspondence and non-product files
Program Clerk
– Responsible for maintaining technical records of team in programming-product library
– Trained as secretary
– Logs all input/output for filing and indexing
– Archiving and source management
– Makes code available for the team to review
– Configuration management?
Toolsmith
– Available to build customised utilities on request of surgeon
– Can be called on to write procedures, libraries, macros etc
– Any special tools for this specific project (not COTS)
Tester
– Devises test cases and data from functional specification
– Tests releases in an adversarial fashion
– Responsible for building test harnesses
– Plans test sequences for unit and regression tests
Language Lawyer
– Experts in syntax and semantics of languages used in the project
– Knows neat and efficient ways of doing things
– Encyclopaedic knowledge of APIs and libraries

One creative genius drives team production
- But supporting roles are no less important
- Surgeon focuses on designing and developing the system
- Freed up from supporting but essential activities
- Radically different from projects where each person does their own design development and testing
- Role specialisation is critical to gaining the increases in productivity over the “average” programmer
- Surgeon has unilateral control over decisions

Monday, November 8, 2010

TDD Cheat Sheet

http://www.bbv.ch/pdf_files/Clean_TDD_Cheat_Sheet_V1.1.pdf

Wednesday, November 3, 2010

API Design

http://digitheadslabnotebook.blogspot.com/2010/07/how-to-design-good-apis.html

http://www.infoq.com/articles/API-Design-Joshua-Bloch

Michi Henning - API Design Matters

https://netfiles.uiuc.edu/dig/papers/API_Evolution.pdf

CatchUp! Capturing and Replaying Refactorings to Support API Evolution

Wednesday, October 20, 2010

security reading

http://www.web4j.com/Java_Web_Application_Framework_Overview.jsp

http://en.wikipedia.org/wiki/Cross-site_request_forgery

http://en.wikipedia.org/wiki/Replay_attack

http://en.wikipedia.org/wiki/Passive_wiretapping

http://en.wikipedia.org/wiki/Steganography

Sunday, September 12, 2010

Eclipse - Shortcut Keys

Block Select Mode: Alt + Shift + A

Mouse Hover: Ctrl + 1, Ctrl + 3

Incremental Search: Ctrl + J

Java Search: Ctrl + H

Refactor Menu: Alt + Shift + T

Change Method Signature: Alt + Shift + C

Extract Method: Alt + Shift + M

Format Code: Ctrl + Shift + F

Move: Alt + Shift + V

Re-Run: Ctrl + F11 (For CTRL+F11 to work the way you want, you must set (from "Windows/Preferences") the "Run/debug > Launching : Launch Operation" setting to: Always launch the previously launched application)

Shift Code Down 1 Line: Alt + Down

Shift Code Up 1 Line: Alt + Up

Inline: Alt + Shift + I

Show Javadoc: Shift + F2

Convert to Uppercase: Ctrl + Shift X

Convert to Lowercase: Ctrl + Shift Y

Focus Package Explorer: Alt + Shift + Q, P

Run JUnit Plugin Test: Alt + Shift + X, P

Collapse all Branches: Ctrl + Shift + /

Quick Type Hierarchy: Ctrl + T

Copy current line to below : Ctrl+Alt+Down

Copy current line to above : Ctrl+Alt+Up

Surround With: Alt + Shift + Z

Display occurrences in file: Ctrl + Shift + U

Add import: Ctrl + Shift + M

Toggle Breakpoint: Ctrl + Shift + B

Next Perspective: Ctrl + F8

Next View: Ctrl + F7

Editor View: F12

Toggle Mark Occurrences: Alt + Shift + O

Static Imports...
Favourites section under Window->Preferences->Java->Editor->Content Assist
If you use org.junit.Assert a lot, you might find some value to adding it there

Eclipse - Missing Functionality

~~Find in Files~~ … Search -> File

~~Search and Replace in Files~~ … Search -> File, then right click Replace…

Subversion Highlight diffs in editor

Subversion jump between changes

Subversion automatically ‘svn add’ new classes

Subversion nice diff dialog

Copy-Paste Buffer

Compare With Clipboard

mvn.bat -- change colour depending on build outcome

Got this idea from Erik Dornenburg at a Thoughtworks briefing...

Add to start of mvn.bat:
@REM yellow on black
color 0E

...

Append to end of mvn.bat:
if ERRORLEVEL 1 goto red
:green
color 2f
goto final
:red
color 4f
:final

@Transactional autowiring problem

Given this bean1 that contains bean2

Bean1:

@Component

public class ServiceImpl implements Service {

@Autowired

private DelegateService m_delegate;

...

}

Breaks when using @Transactional on the delegate component:

@Component

@Transactional

public class DelegateService implements Service {

...

}

With this exception:

java.lang.IllegalStateException: Failed to load ApplicationContext

at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:201)

at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)

at org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)

at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:255)

at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:111)

at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:148)

at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)

at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)

at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)

at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)

at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)

at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)

at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)

at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ServiceImpl': Autowiring of fields failed; nested exception is Could not autowire field: private com.service.DelegateService com.service.ServiceImpl.m_Service; nested exception is java.lang.IllegalArgumentException: Can not set com.service.DelegateService field com.service.ServiceImpl.m_delegate to $Proxy32

at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessAfterInstantiation(AutowiredAnnotationBeanPostProcessor.java:243)

at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:959)

at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:472)

at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)

at java.security.AccessController.doPrivileged(Native Method)

at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)

at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)

at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)

at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)

at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)

at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)

at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)

at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)

at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:380)

at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:84)

at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:42)

at org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:173)

at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:197)

... 17 more

Same thing happens if @Transactional is applied at the method level instead of class level.

Solution is to @Autowire the delegate with resource name.

Spring Links

Spring 2.5

The Spring Framework - Reference Documentation

Annotation-based configuration

Fine-tuning annotation-based autowiring with qualifiers

Classpath scanning for managed components

Spring 3.0

Reference Documentation

Upgrading to Spring 3.0

Spring Framework 3.0 M2 released | SpringSource Team Blog

New stuff in Spring 3.0 « Spring in Practice

mvn eclipse:eclipse is not pulling in dependencies properly

“mvn eclipse:eclipse” generates a .classpath but the transitive dependencies are sometimes different to those reported by “mvn dependency:tree” (and used to generate a war file)

See this page:

mvn eclipse:eclipse is not pulling in dependencies properly: https://jira.kuali.org/browse/KULRICE-1760

Forcing a change to the .classpath file does not help Eclipse tomcat servers (they still pick up what “mvn eclipse:eclipse” generated).

SVN Update Batch Script

update.bat:

start TortoiseProc.exe /command:update /path:"d:\work\1" /closeonend:0

start TortoiseProc.exe /command:update /path:"d:\work\2" /closeonend:0

start TortoiseProc.exe /command:update /path:"d:\work\3" /closeonend:0

start TortoiseProc.exe /command:update /path:"d:\work\4" /closeonend:0

start TortoiseProc.exe /command:update /path:"d:\work\5" /closeonend:0

http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-automation.html

JMX and DEBUG options for Tomcat

JMX:

export CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

DEBUG:

export JPDA_ADDRESS=8888

export JPDA_TRANSPORT=dt_socket

catalina.sh jpda start

Wednesday, September 8, 2010

Tony Hoare Billion Dollar Mistake Transcript

Transcript from Tony Hoare's presentation on the danger of nulls.

Don’t know how much it’s cost the IT industry. Somewhere in the order of $100m - $10bn
How I came to make this rather bad idea.
ALGOL-60
Reference to array with subscript
Check every subscript agains the array bounds on every access to an array – historically good idea.
Java has reproduced this decision made 30 years ago

Extension of ALGOL-60 committee designed successor to ALGOL-60
Hoare suggested “record handling” – concept of object, an object to which reference could be made via a pointer
Bitter experience with machine code using pointers, indirect addressing – wreak ultimate havoc on program because if you happen to use a floating point number or integer as pointer and update contents of whatever location it was pointing to, it was likely as not you would update a piece of your own code.
Took it for granted that for every var or attribute that could take a ref as its value, the programmer must declare type of location of that pointer. Standard for languages like C++.
Pointer types can be checked at compile time.
Discovered years ago that this was quite an original idea. No other language checked the types of variables at indirect addresses pointed to by pointers.
Great thing about record handling was that if you structured your data as a set of records you would never have a subscript error – no need to test whether a pointer is within range - you cannot construct a pointer that doesn’t point to something that exists and is of the expected type. That is logically impossible and so here is a whole class of errors that can never happen again. Good idea to do this checking at compile-time because there was a time penalty in doing subscript checking in ALGOL compiler. Asked customers if they’d like option of switching off type checking after they’d tested the programs. Once said that removing type checking from your running programs and using them only for testing is like wearing a life jacket on your practice emergency drills and taking them off as soon as your ship was really sinking. But customers where asked if they’d like the option of taking the life jacket off – they said no. Never put the option in. But still it was a very serious mistake for Elliots. Because a lot of potential customers were Fortran users rather than ALGOL. Translate from Fortran to ALGOL. Disaster. No Fortran user would touch it. They couldn’t run any of their programs – subscript error. User’s didn’t care about subscript error – just wanted it to run like it did on their machines.

So, everything so far seems fine. We’ve got our object-orientation with careful type-checking of all the pointers, safe and there’s no overhead. Testing every subscript for its correctness.
And then I went and invented a null pointer.
And if you use a null pointer you either have to check every reference or you risk disaster – most people of course (like Fortran programmers) would prefer to risk disaster, and indeed suffer disaster, rather than check all their subscripts. I didn’t know that at the time but my friend Dykstra who was also working with the team developing ALGOL-60 thought the null reference was a bad idea and he gave a very subtle and abstract reason for it. He said if you have a null reference, then every bachelor who you’d represent in your object structure would seem to be polygamously or rather polyandorously to the same person that’s called her “nuller”. I thought that was rather a nice criticism but my real criticism is that it brings back again unnecessarily all the agony of having to choose whether to run your program fast without checking or run it slow with checking.

Now, I did know that there was a solution to this problem. It was based on the idea of discrimination between objects belonging to a disjoint union class. Idea I got from pure mathematics is that of a disjoint union that is a union between two sets which have no members in common. So a language can quite reasonably have a facility for declaring a new class not as the Cartesian product of attributes drawn from other classes but rather as a disjoint union of various other classes. E.g. if you had a class of vehicles you might classify them as either busses or private cars and separately declaring different structures of attributes for those two classes. Bus has max passengers and private car has capacity of trunk/boot. And every time you accessed either of those components of the object you would have to do it within a discrimination clause which tested. It looked at the vehicle and say when it is a bus you can look at max passengers, when it’s a car you can look at its capacity. But size of source program gets quite a bit larger by having to make all these discrimination clauses and you have to deal with both cases separately. If we insisted on a discrimination clause then we should make null not into a value of a pointer but rather into a class – a class which never had any objects in it and which only had one pointer which obviously didn’t point to any objects. So now whenever you wanted to have a null pointer you would declare your pointer to be either a pointer to the null class or a pointer to the Vehicle class or the Wife class and that would give you a way of specifying whether you wanted this pointer to be able to take a null value or not or whether you wanted it to remain definitely pointing to something and you would never have to test.

Cumbersome. Lots of corner cases. What happens if you assign a new value to the pointer which you are currently analysing and assuming to be a member of the Bus class?
Even worse problem with initialisation. One of the things you want a high-level language to do for you is to protect you against uninitialized variables. Standard way of doing that is to assign a fixed known value to every variable or attribute and null is a very – well it’s really the only – certain thing that you can assign as a value of an attribute to a recently created pointer or pointer attribute. And so if you want to avoid using null then you have to invent a whole sub-language to use for initialising pointers that aren’t allowed to be null. This is alright as long as all your objects are in a tree structure, because you can then start with the leaves of the tree, build up in a hierarchical and well-ordered fashion the value of a little tree network to be the initial value of your new variable. But if you wanted to create a cyclic structure this way there’s no way of doing it. You would assign a null value to the pointer and later on you would insert the cyclic pointer to somewhere else in the tree. All those problems in the end I didn’t want to deal with and that led me to suggest that a null pointer was a possible value of every reference variable and the possible mistake on every use of that reference variable. And perhaps it was a billion-dollar mistake.

Well the world is gradually recovering from the mistake I’m glad to say. Modern languages like C# and Spec# and Java are introducing the idea of reference declarations which are declared to be non-null and reference parameters which are declared to be non-null and compile-time checking which checks that such variables do not have, could not possible have null values. And they have had to tackle all the problems of initialisation and discrimination in a context which is now very much more complicated than I’d ever thought of all the contexts of overloading and inheritance makes the concept of initialisation very much more elaborate than I would ever have dreamt of. But that is what is happening. I think the movement must have been motivated that null references were an expensive mistake.

Billion dollars... put things in reasonable proportion... I did feel I ought to take responsibility for this mistake, but since it was unlikely I’d every be able to pay back a billion dollars I would keep rather quiet about it – so don’t tell anyone about it please.

I put forward the view (which really derived from making ALGOL octal dump proof) that a programming language designer should be responsible for the mistakes that are made by the programmers using the language. And that means, since programming language design is rather a serious engineering activity – not one that you give to shall we say programmers with 9 months experience in machine code programming [referring to self] – but rather one which requires a good scientific basis, good understanding, ingenuity, invention, a lot of control of detail and a clear objective that the programs are written by people using that language would be proof against at least certain kinds of errors and at least as easy as possible to get right, not full of little traps and syntactic awkwardnesses that people are constantly bumping their toes against.

This was the view that led to me idea of using proof, formal verification of programs, as logical and mathematical models is a method of conducting research into the design of good languages. I wasn’t too optimistic in 1969 about the likelihood that people out there would actually be using proofs to guarantee the correctness of their programs at least not in the immediate future – in fact not for the next 30 years was my prediction – but that by investigating the logical properties of your programming language and finding out how difficult it would be to prove correctness if you wanted to you would get an objective measurement of how easy the language was to use. So if the proof of program correctness requires a very large number different proof rules and if each proof rule has a lot of side conditions, in particular, if the validity of the local application of a rule to a small bit of program depends on properties which can only be established by a scan of a program as a whole then you know you’ve done a bad job as a language designer and you do not need your customers to tell you that. Mind you they don’t because it’s actually very easy to persuade the customers of your language that every thing that goes wrong is their fault not yours. But I rejected that and thought that no, language design is a serious scientific engineering activity and we should begin to take responsibility for mistakes our users make when they use our languages. It’s beginning to happen again – Java and its successors have all used avoidance of error as one of the criteria that they use in the detail design of new features of the language. Of course it’s only one of the criteria and it’s not or at least it wasn’t at the time the most important criteria. The most important criteria is of course compatibility with every thing that has gone before – you can’t throw away millions of lines of code that have been written in other languages. Every commercial product you have to make concessions to the commercial and historical reality – you cannot pursue an ideal to its limit. But gradually ideas changes, programmers get more interested in correctness and demonstrable correctness and production techniques and checkers, analytical tools, testcase generators and so on that are going to help them get their programs correct.

The analogy that I draw is with agricultural pollution and vehicle safety. When Ralph Nader first started publishing his books on Unsafe At Any Speed it had no connection with the market place – the customers where just not asking for reliability or safety as one of the properties of their vehicles. But gradually, over 30 years, customer feeling about unreliable vehicles has changed with the aid of law-making, there are legal constraints now which require basic standards of safety into every vehicle sold. And so there is a possibility that the marketplace and the commercial necessity will move in the direction of greater reliability of programs and the languages in which their expressed.

You know what’s driving this move towards more ideal programming languages? It’s not idealism – although I think for many professional engineers they do have ideals and they do pursue them in preference to not pursuing them whenever the opportunity arises. No the real commercial imperative which requires greater attention paid to formal correctness of the programs is the virus. See the virus/malware/worm enters your computer and does dreadful things to it. It reaches parts of your program that normal execution never reaches. So it’s no longer adequate to test your program against all the cases that are likely to arise, because even if you do the virus will find a case that is not likely to arise. So it forces you to get the whole program correct, not just the parts that are going to be used by your customers. You’ve got to get the parts that will be used by viruses correct too. And that can’t be done by testing – it has to be done by analysis of the source code using type-checking techniques (simplest) but increasingly more sophisticated reasoning techniques are being applied to high-volume code to check that it doesn’t contain any naughty things like null reference de-referencing.

Well if I’m responsible for a billion-dollar mistake I think my reason for bringing it up it is only to put even more blame elsewhere. The designers of C [shakes his finger]. Well, one can definitely quantifier because the buffer overflow is a direct result of the “get” routine in C which does not check the subscript bounds of the string that it is asked to input. That allowed the early very simple viruses to get in by overwriting the return pointers in the code and these viruses taught the world how to write malware. Without this very simple entry it’s quite possible that nobody would ever have thought to look for the more subtle things which are now being exploited every day by people who are now motivated and skilled and whose profession and income it is to write botware/malware. So if it hadn’t been for the
“get” routine of C we might have had no malware. Now one virus “Code Red” was estimated to have cost the world economy $4bn because it really brought down all the networks in the world, interruptions to business/banking

Sunday, September 5, 2010

NULLs are not the same in SQL and Java

http://blogs.msdn.com/b/ericlippert/archive/2009/10/29/i-have-a-fit-but-a-lack-of-focus.aspx

In SQL, NULL really means "unknown". Of course, when you compare one value that is "unknown" to another value that is also "unknown", the result can only be "unknown".
In C# (and Java, etc), null doesn't mean "unknown". It means "there is no object here". The correct way to translate that to relational terms would be to treat every object reference as a reference to a relation which may have either 0 or 1 tuples. Null means 0 tuples. Obviously, two relations with 0 tuples each are definitely equal - "unknown" doesn't enter into equation here.

NULLs in SQL Maths and Strings

http://en.wikipedia.org/wiki/Null_(SQL)

Mathematical and string concatenation

Because Null is not a data value, but a marker for an unknown value, using mathematical operators on Null results in an unknown value, which is represented by Null.^[5] In the following example, multiplying 10 by Null results in Null:

10 * NULL          -- Result is NULL

This can lead to unanticipated results. For instance, when an attempt is made to divide Null by zero, platforms may return Null instead of throwing an expected "data exception - division by zero".^[5] Though this behavior is not defined by the ISO SQL standard many DBMS vendors treat this operation similarly. For instance, the Oracle, PostgreSQL, MySQL Server, and Microsoft SQL Server platforms all return a Null result for the following:

NULL / 0

String concatenation operations, which are common in SQL, also result in Null when one of the operands is Null.^[6] The following example demonstrates the Null result returned by using Null with the SQL || string concatenation operator.

'Fish ' || NULL || 'Chips'   -- Result is NULL

This is not true for all database implementations. In an Oracle RDBMS for example NULL and the empty string are considered the same thing and therefore 'Fish ' || NULL || 'Chips' results in 'Fish Chips'.

Nulls in SELECTs

http://en.wikipedia.org/wiki/Null_(SQL)

Data Manipulation Language

SQL three-valued logic is encountered in Data Manipulation Language (DML) in comparison predicates of DML statements and queries. The WHERE clause causes the DML statement to act on only those rows for which the predicate evaluates to True. Rows for which the predicate evaluates to either False or Unknown are not acted on by INSERT, UPDATE, or DELETE DML statements, and are discarded by SELECT queries. Interpreting Unknown and False as the same logical result is a common error encountered while dealing with Nulls.^[2] The following simple example demonstrates this fallacy:

SELECT * 
FROM t 
WHERE i = NULL;

The example query above logically always returns zero rows because the comparison of the i column with Null always returns Unknown, even for those rows where i is Null. The Unknown result causes the SELECT statement to summarily discard each and every row. (However, in practice, some SQL tools will retrieve rows using a comparison with Null.)

The dangerous subtleties of LEFT JOIN and COUNT() in SQL

http://www.xaprb.com/blog/2009/04/08/the-dangerous-subtleties-of-left-join-and-count-in-sql/

NULLs and the Database

Database:
Oracle is not a relational database: http://www.webopedia.com/TERM/C/Codds_Rules.html

You'll see here that Codd is actually agreeing with nulls - which annoyed Date and they had a whole series of articles on what nulls mean and why it's a mistake - in the late 80s, early 90s. Basically
Date seemed to win the debate - at least in my mind.

http://www.amazon.com/Relational-Database-Writings-1989-1991-Date/dp/0201543036/
http://www.amazon.com/Relational-Database-Writings-1991-1994-Date/dp/0201824590/

Date was saying that nulls lead to 3 values logic (3VL) which leads to errors in logic things like NULL AND T in truth tables for examples - nulls make no logical sense - and as a system based on relations and logic it's a bad system.

Trivalent Logic:

Hibernate UserType
There's a reasonable example: http://i-proving.ca/space/Technologies/Hibernate/User+Types+in+Hibernate

This one lets nulls but combines readResolve(). http://community.jboss.org/wiki/UserTypeforpersistingaTypesafeEnumerationwithaVARCHARcolumn

Thoughts on the counter arguments??: http://mooneyblog.mmdbsolutions.com/index.php/2010/04/14/quick-rant-on-why-database-nulls-are-not-necessarily-evil/
Nulls aren't evil. They aren't logical - they're simply a mistake.
A good article about a different domain (Geo science) and how missing data, nulls and the problems that there are: http://portal.acm.org/citation.cfm?id=1296606

Calculations with NULL
Basically you can't compute on null - hence NPE.

Another example is that COUNT counts nulls but other aggregates don't (AVG and SUM). If nulls were values why can't you average them or sum them? Why can you count them?

Relational databases are based on relations and set theory. Sets are empty - they aren't null. And semantics with a good foundation in maths makes the whole thing just generally better (another book "Third Manifesto" goes into some detail about what a proper relational database would look like).

Another Date book really describes what an outerjoin (again nulls cause problems there) is and so on: http://www.xaprb.com/blog/2009/03/29/a-review-of-sql-and-relational-theory-by-c-j-date/

The guy that introduced NULLs into SQL and RDBMSs (Codd), said later that one null was inadequate and SQL should be enhanced to allow for two nulls: 1 for unset (Missing but Applicable), 1 for missing (Missing but Inapplicable) http://en.wikipedia.org/wiki/Null_%28SQL%29

“Should Nulls be considered harmful?” http://www.firstsql.com/inulls.htm
“How To Handle Missing Information Without Using NULL” http://www.dcs.warwick.ac.uk/~hugh/TTM/Missing-info-without-nulls.pdf

How to protect from Nulls in Java

(with thanks to Andrew Newman for a lot of these ideas)

How to protect from Nulls...
Each public method in each class rejects any null values with an IllegalArgumentException.
This is enforced by test cases - each test case extends from a common TestCase that checks public methods by ensuring they throw exception when null is passed in.

No objects exist with nulls as values.
All classes have default values (objects) that can be persisted to the Database. Have default values like "". Or optional values (like something not yet done) are separate relations.

Null Value Object and Serialization

http://www.javalobby.org/java/forums/t17491.html

class Xxx {

    public static EMPTY_XXX = new Xxx();

...

    private Object readResolve() {

        return EMPTY_XXX;

}

}

You should write code that checks that == works - as a suite of tests too. Like AssertSerialization.

Null-safe operators in Java 7:

Thursday, August 26, 2010

Tortoise from the command line

http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-automation.html

update.bat:
start TortoiseProc.exe /command:update /path:"d:\work\1" /closeonend:0
start TortoiseProc.exe /command:update /path:"d:\work\2" /closeonend:0
start TortoiseProc.exe /command:update /path:"d:\work\3" /closeonend:0
start TortoiseProc.exe /command:update /path:"d:\work\4" /closeonend:0
start TortoiseProc.exe /command:update /path:"d:\work\5" /closeonend:0

Monday, July 5, 2010

online java long to date converter

http://www.esqsoft.com/javascript_examples/date-to-epoch.htm

Friday, June 18, 2010

Cargo Cults vs the Good Guys

Full View

[Brisbane XP] Cargo Cults vs the Good Guys

...

From:	RM ... Add to Contacts
To:	brisbane-xp@googlegroups.com

Well, here goes ...

As a seed for further conversation, here's my reference-grab doc used to form my research essay. It is the set of summaries, quotations and paraphrases from the handful of texts that I grabbed intending to ponder the enablers for scaling a software dev operation. The headings mirror my essay's basic framework. (This is obviously not my essay, this is just the literature review snapshot.)

If you've already read these books, consider the exercise either passe or just a refresh. If not, worth a glance through I think. This isn't a "wikipedia" of these texts, it's just a grab of the slices out of them that helped me think about management challenges in running a scalable software dev business in general. I recommend reading the books!

There are inline comments (eg: [D01]) put in by the fellow who is the target audience of the essay. I don't know whether the links/anchors will work ... this is just what Thunderbird did after a cut and paste from Word.

Here's my reading list ...

Leffingwell, D. (2007). Scaling Software Agility: Best Practices for Large Enterprises. Boston, MA: Addison-Wesley.

Shine Technologies. (2003). Agile Methodologies Survey Results. http://www.shinetech.com/attachments/104_ShineTechAgileSurvey2003-01-17.pdf

Larman, C. & Vodde, B. (2010). Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Boston, MA: Addison-Wesley.

Eckstein, J. (2004). Agile Software Development in the Large: Diving Into the Deep. New York: Dorset House. [couldn't obtain the book but would like to, took some ideas and a single quote from a 'net snapshot of the intro]

Fisher, R, Ury, W & Patton, B. (1991). “Getting to Yes”: Negotiating Agreement Without Giving In (Second Ed). New York: Houghton Mifflin

Beck, K. & Andres, C. (2004). Extreme Programming Explained: Embrace Change. Boston, MA: Addison-Wesley.

Demarco, T. & Lister, T. (1999). Peopleware: Productive Projects And Teams. town, STATE: Dorset House.

Yourdan, E. (1996). Rise and Resurrection of the American Programmer. Englewood Cliffs, NJ: Prentice-Hall.

Yourdan, E. (1993). Decline and Fall of the American Programmer. Englewood Cliffs, NJ: Prentice-Hall. [didn't read the entire text, but will do]

Brooks, F.P. (1975). The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley.

Gartner, M (2010). Markus Gärtner's blog: Software Testing, Craftsmanship, Leadership and beyond “Listen to the old ones, or re-invent the wheel.” http://blog.shino.de/2010/02/28/listen-to-the-old-ones-or-re-invent-the-wheel/

Here's the snapshots I used. (No apologies for repetition, spelling or grammar errors.)

Scaling Software Development Teams

1 Issue Analysis

1.1 Aim of this Section

(Brooks, 1975, p3)

Dutch Proverb: “A ship on the beach is a lighthouse to the sea.”

1.2 Issue Clarification

1.2.1 Current Drivers

(Demarco & Lister, 1999, pp3-4)

“We observe that about fifteen percent of all projects studied came to naught …For bigger projects … twenty-five percent of projects that lasted twenty-five work-years or more failed to complete.

(Demarco & Lister, 1999, pp3-4)

For the overwhelming majority of the bankrupt projects we studied, there was not a single technological issue to explain the failure, The cause of failure most frequently cited by our survey participants was …the project's sociology.”

(Eckstein 2004, p5)

“… question the feasibility of agile software development in the large, ….The reason most (large) projects fail is a lack of communication … Communication is one of the focal points of agile processes. But can effective communication ever be established successfully for large teams?” Eckstein (2004)

(Brooks, 1975, p14)

“More software projects have gone awry for lack of calendar time than for all other causes combined. … estimating … confuse effort with progress [scaling failure] … [unwillingness to revise schedule] … schedule is poorly monitored … [adding manpower slows progress – scaling failure]”

(Brooks, 1975, pp41-50)

a single dictatorial architect, all other follow the pattern faithfully and unswervingly

(Brooks, 1975, pp142-144)

top-down design and structured procedural programming

(Beck, 2004, p105)

the “building construction” metaphor of “design everything up front” is a failure for software dev, design on the fly and modify requirements, design and outcome together

(Larman & Vodde, 2010, p329)

gardening metaphor, rather than "building construction"

[DO1]

(Beck, 2004, pp131-133)

“Taylorism” or “Scientific management” assumes: plans can be run through to completion as written, micro-optimisation leads to macro-optimisation, and people are interchangeable or should be made so. Manifestation of this are the separation of design, execution and quality, all of which unite in an XP paradigm

(Larman & Vodde, 2010, p338)

adding more resources late in a slowing project while retaining the fixed end date is a almost certain catastrophe[DO2]

(Brooks, 1975, p47)

“… refrain from hiring implementers until the specifications are complete. This is what is done when a building is constructed.”

(Brooks, 1975, p74)

principal challenge in large-scale Waterfall is to control and enable the communications between the players

(Brooks, 1975, p16)

“Men and Months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.”

(Brooks, 1975, pp17-18)

the communications burden in Waterfall amounts to mapping the number of relationships created by the division of work and allowing for training, hand-off, and task-fulfilment communications

(Demarco & Lister, 1999, pp44-50)

“Three rules of thumb seem to apply whenever you measure variations in performance over a sample of individuals:

• Count on the best people outperforming the worst by about 10:1.

• Count on the best performer being about 2.5 times better than the median performer.

• Count on the half that are better-than-median performers outdoing the other half by more than 2:1.

The top quartile, those who did the exercise most rapidly and effectively, work in space that is substantially different from that of the bottom quartile. The-top performers' space is quieter, more private, better protected from interruption, and there is more of it.”

[DO3]

(Yourdan, 1996, pp30,33)

the “social contract” of loyalty has been broken by the aggressive and unapologetic downsizing of the 1990s, so employees now don’t expect or give employment loyalty. Small companies have an advantage of closeness and a sensation of “shared risk”, reaffirming the “social contract of loyalty.

(Yourdan, 1996, p175)

Waterfall doesn’t work because “bored people don’t work hard”

(Demarco & Lister, 1999, p7)

formula for disengaging thought workers is to treat them like production line workers: eliminating error, being tough on “goofing off”, people being interchangeable and dispensable, optimising the “steady-state” rather than embracing change, standardising everything, and eliminating risk and experimentation.

(Demarco & Lister, 1999, p7)

1.2.2 Barriers

(Larman & Vodde, 2010, (pp499-545)

if contracts are involved, engage lawyers early and often and educate them in the Agile payoffs, avoid fixed scope/price/date contracts, try variable price/progress contracts or target-cost contracts where the costs and profits are declared up front and the pain and gain are both shared.

1.3 Impact on Stakeholder/s

(Leffingwell, 2007, p7,96-99, 101-187) agile core practices that scale natively:

“Self-organising self-managed define/build/test component teams
Two levels of work planning and tracking are in use
Mastering (the internal mechanics) of the work iteration
Smaller, more frequent releases quarterly, rather than 2 year
Concurrent testing - unit and acceptance
Continuous Integration – source control and automated builds
Regular reflection and adaptation – iteration and release retrospectives”

(Leffingwell, 2007, pp7-8, 190-193, 195-326) supplementary practices required at scale:

“Intentional architecture – breaking up the system into separable components with interfaces and skill boundaries
Lean requirements definition – a vision, a roadmap, and a just-in-time requirements elaboration
Systems of systems and the agile release train – immovably fix releases onto a date line and flex the content rather than the delivery date
Mechanisms for managing highly distributed teams – tooling that supports time-zoned meetings – video conferencing, wikis
Impact on customers and operations – consideration of the work required by marketing, sales, training, finance depts, to accommodate frequency and difference of releases.
Changing the organisation – Agile tends to identify systemic weaknesses in the rest of the organisation not being able to keep up, requires executive buy-in
Measuring business performance – score-carding systems”

(Larman & Vodde, 2010, p10)

Large scale Scrum using pattern “Framework 1” – up to ten scrum teams.

Large scale Scrum using pattern “Framework 2” – more than ten scrum teams.

1.4 Summary: Need for action

(Shine, 2003)

Regarding their survey of Agile users’ experience of Agile software development methodologies:

“84.7% of respondents rated their Agile knowledge as average or above.

Of these respondents:

49% stated that costs were reduced or significantly reduced
46% stated that costs were unchanged, resulting in 95% stating that there was either no effect or a cost reduction
Only 5% stated that Agile processes had a negative effect on cost
93% stated that productivity was better or significantly better
88% stated that quality was better or significantly better
83% stated that business satisfaction was better or significantly better
these respondents were vastly more in favour of Agile processes. Only 1.8% of knowledgeable respondents found productivity degradations, but this increased to 3.1% when taken across all respondents.”

2 Proposed/Recommended Solutions

2.1 Aim of this Section

2.2 Managing the Methodology

2.2.1 Understand the Methodologies

(Leffingwell, 2007, p xxi) waterfall is better than “cut and try”

(Leffingwell, 2007, p xxiii) waterfall needs more time for requirements and architectural runway

(Leffingwell, 2007, p20) waterfalls problems are that

requirements are often unknown even to the final users
requirements change as time passes
the design cannot be so well constructed that integration of the many parts will be smooth
innovation cannot be done to a schedule

(Leffingwell, 2007, p17) waterfall needs a significant prototyping phase to succeed, and thorough expertise on the part of the involved.[DO4]

(Leffingwell, 2007, p18) waterfall integration can be a looming disaster

(Leffingwell, 2007, p18) waterfall does provide an open book, up front method for known buildable systems

(Leffingwell, 2007, p26)

Agile responds to and accommodates these by

Presuming that requirements need to be discovered during development
Presuming the requirements may change during the development
Use of continuous integration rather than ultimate integration
Presume that innovation is risky and unpredictable

(Eckstein 2004, p4)

“The big difference between these more modern applications and more traditional applications is that the modern ones must be available in the market quickly. ... Heavy-weight processes of the 1980’s and 1990’s have difficulties dealing with these new requirements. They have instead occasionally been successful in domains with stable requirements.”

(Brooks, 1975, p45)

design by definition of the user interface, via the user manual as the driving document

(Brooks, 1975, p47)

externally set architecture frees the programmer to focus their creativity on maximally achieving their task scope

(Brooks, 1975, p117)

Requirements change on the fly and are only exposed during product creation

(Larman & Vodde, 2010, p68)

Agile used in nuclear power control systems

(Leffingwell, 2007, p85)

Frequent delivery of small segments uncovers risk early.

(Leffingwell, 2007, pp7-8) Summarises the key practices in XP:

Five to Ten programmers, collocated, with a customer liaison on site
Frequent build iterations, each fully releasable with an increment of functionality
User “stories” are used to specify the increment
Programmers work in pairs on a single PC[DO5]
The design emerges through the process of development

(Leffingwell, 2007, pp7-8, 41, 43-45, 48) Summarises the key ideas behind Scrum:

Small teams of eight or less are formed with all the skills necessary to fully complete a given list of feature implementations for a product
These teams are long-lived, not disbanded after-task
Iterations called Sprints are fixed duration, strongly recommended as two weeks, but from one to four weeks is known
Work within the sprint is locked from outside influence once launched.
All work for a product is centrally listed in one product-wide backlog list. Any number of teams can pull items off this single list when defining their sprints.
The sprint team is self-organising regarding the work, and they have a person designated as a scrum master, who is not also a line-manager for the team
A daily meeting called the “stand-up” is used to oblige conversation and identify slow-downs
There is a strict focus on “time-boxing” – all processes are confined to defined times and enforced.
Usually Scrum sprints are bundled into 3 monthly releases, so as not to disrupt customer experience with too-frequent releases.
The team is responsible to solve all issues with their Sprint backlog
The Sprint backlog is prioritised in must-do, should-do, want-to-do and not all work needs be completed.
Team members are continually learning

[DO6]

(Larman & Vodde, 2010, pp120-121)

Product owner needs to be responsible for the release’s ROI, choice of content at each iteration according to market value, and can accept or reject the outcomes.

(Larman & Vodde, 2010, p305)

build a walking skeleton, then pack on the flesh

(Larman & Vodde, 2010, p307)

risk-driven development – “build the customer features that have the most architectural impact first”[DO7]

(Brooks, 1975, p111)

Conway’s Law: “Organisations which define systems are constrained to produce systems which are copies of the communications structures of these organisations.”

2.2.2 Choose your Methodology

(Leffingwell, 2007, p77)

Management in Waterfall is typified by initially fixing dates and scope, prescribing work, contractual sign-offs, enforcement of scope-of-works, demonstration on completion and reviewing by weekly status meetings.

(Leffingwell, 2007, p77)

Management in Agile is typified by initially teams bidding for work scope and selecting their means, collaborative learning, enforcing the date rather than the scope, demonstrating continuously, and reviewing by daily stand-ups.

(Leffingwell, 2007, p5) successful businesses are first to market, solve customers’ pain points, give required quality and functionality, adapt quickly to business and technology changes

(Larman & Vodde, 2010, p68)

Agile used in nuclear power control systems

(Larman & Vodde, 2010, p335)

legacy code has two sources – fixed scope for a date and poor development skills

(Larman & Vodde, 2010, pp346-347)

to deal with legacy code, clean up the neighbourhood while working and rewrite highly defective code

(Beck, 2004, p82)

pairs are more than twice as productive while paired

(Yourdan, 1996, p170)

recommends ditching Waterfall for Agile and particularly Scrum

(Yourdan, 1996, p171)

some elements can’t be planned prior to commencing work

(Yourdan, 1996, pp175-176)

many successful software deployments have been by “guerrilla teams” working in unorthodox ways rather than big IT houses,

2.2.3 Execute your Methodology

(Larman & Vodde, 2010, p81)

treat test code as being as important as production code

(Larman & Vodde, 2010, p386)

Avoid commercially-branded “versions” of Agile

(Yourdan, 1996, p137)

Airlie Council and Microsoft in some sections write the user manual first as the specification and then set about design and implementation

(Yourdan, 1996, p160)

the key to operating a waterfall plan effectively is to be prepared to dynamically change the mix of time, scope and quality and the customer should be the one driving this choice

(Yourdan, 1996, p167)

Do quality in-line with the task, not as an item at the start or end

(Brooks, 1975, pp155-156)

rule a Waterfall by PERT chart

(Brooks, 1975, p157)

mandatory reporting of issues up managerial lines is necessary to prevent project catastrophe

2.2.4 Scale your Methodology

(Larman & Vodde, 2010, p132)

Keep one product backlog for all work.

(Leffingwell, 2007, p39)

XP is best applicable to collocated teams of ten or less, however it can be scaled

(Leffingwell, 2007, p48)

Scrum becomes difficult in large and distributed teams, where continuous integration and testing are not feasible or where the culture resists empowerment or change.

Reference the texts, learn, don’t fly blind.

(Leffingwell, 2007, p7,96-99, 101-187) agile core practices that scale natively:

“Self-organising self-managed define/build/test component teams
Two levels of work planning and tracking are in use
Mastering (the internal mechanics) of the work iteration
Smaller, more frequent releases quarterly, rather than 2 year
Concurrent testing - unit and acceptance
Continuous Integration – source control and automated builds
Regular reflection and adaptation – iteration and release retrospectives”

(Leffingwell, 2007, pp7-8, 190-193, 195-326) supplementary practices required at scale:

“Intentional architecture – breaking up the system into separable components with interfaces and skill boundaries
Lean requirements definition – a vision, a roadmap, and a just-in-time requirements elaboration
Systems of systems and the agile release train – immovably fix releases onto a date line and flex the content rather than the delivery date
Mechanisms for managing highly distributed teams – tooling that supports time-zoned meetings – video conferencing, wikis
Impact on customers and operations – consideration of the work required by marketing, sales, training, finance depts, to accommodate frequency and difference of releases.
Changing the organisation – Agile tends to identify systemic weaknesses in the rest of the organisation not being able to keep up, requires executive buy-in
Measuring business performance – score-carding systems”

(Larman & Vodde, 2010, p10)

Large scale Scrum using pattern “Framework 1” – up to ten scrum teams.

Large scale Scrum using pattern “Framework 2” – more than ten scrum teams.

(Larman & Vodde, 2010, p135)

Large product, break up into Product Areas and have Area Backlogs.

(Larman & Vodde, 2010, p406)

spend money on improving rather than upsizing

(Beck, 2004, pp23-34)

shrink teams as they increase internal capability, form new teams with the departed

Multisite teams

(Larman & Vodde, 2010, p416)

Multisite is handled similarly to collocated teams – the teams are given a feature list to implement per sprint and they act on it in the same way as if they were local.

(Larman & Vodde, 2010, p417)

Synchronise iterations across the company

(Larman & Vodde, 2010, pp418-421)

Collocate members of a single team

(Larman & Vodde, 2010, pp422-423)

Train people at existing sites, rather than starting a new team site

(Larman & Vodde, 2010, pp423-424)

treat sites equally

(Larman & Vodde, 2010, pp425-428,469-473)

use video

(Larman & Vodde, 2010, p433)

cross-site CsoP

(Larman & Vodde, 2010, p433)

scrum masters act as common-interest “matchmakers” for team members

(Larman & Vodde, 2010, (pp437-438,458,467-468)

train people in cross-cultural negotiations

(Larman & Vodde, 2010, (p440)

use wikis

offshore teams

(Larman & Vodde, 2010, (pp448-450)

educate your sales dept and customers on Agile

(Larman & Vodde, 2010, (pp450-451)

matchmakers instead of intermediaries between foreign teams

(Larman & Vodde, 2010, (pp454-455)

visit the client or have the client visit your site

(Larman & Vodde, 2010, (p456)

agree to all speak English, rather than have interpreters

(Larman & Vodde, 2010, (p457)

have offshore teams do initial iterations onshore

(Beck, 2004, pp111-112)

scaling: break the problem into smaller problems, distribute and solve simply, clean up any leftover complexities.

(Beck, 2004, p115)

complex problems are solved by pairing complementary domain experts

(Beck, 2004, p115)

refactoring challenges are solved by slowly-but-surely refactoring

(Beck, 2004, pp149-151)

offshoring by merely stacking low-priced coders on a problem is likely to fail due to the inherent difficulties of delivering via the Waterfall model.

(Yourdan, 1996, pp8-9)

communication problems with offshoring dev (ie: in India) – international language problems, culture, requirements are usually not clearly known up-front by users, remotely located users specifying requirements

(Yourdan, 1996, pp12)

Indian/American salary differential is rapidly reducing

(Yourdan, 1996, pp14-17)

Threat is not from India, but from radical improvement techniques like Agile.

(Yourdan, 1996, p176)

IT infrastructures need to be dynamic

(Brooks, 1975, p24)

when faced with a reschedule, reschedule brutally, not trivially[DO8]

(Brooks, 1975, p21-26)

early pre-cursor to a Scrum team pattern, “the surgical team” made up of niche specialists executing their precise tasks in harmony under an overall Waterfall regime.

(Brooks, 1975, p21-26)

Scaling this is about having the team leads in those surgical teams come together as masters to agree the interoperations required between their segments.

(Demarco & Lister, 1999, p12)

bigger problems require more time allocated to thinking, planning, learning, etc

2.3 Managing the Environment

2.3.1 Provide the Right Workspace

(Larman & Vodde, 2010, pp208-209)

better emphasis on shared space, destruction of cubicles and barriers,[DO9]

(Larman & Vodde, 2010, p394)

Remove walls, introduce numerous whiteboards

(Larman & Vodde, 2010, p398)

use open-space to foster ad-hoc meetings

(Yourdan, 1996, pp46-47)

provide decent working conditions, desk space, privacy[DO10], internet access, refreshments

(Demarco & Lister, 1999, pp37-41)

thoughtful arrangement of floor space to enable thought-workers to have both silent thought-flow time and team interaction time is essential and far more productive financially than economising on materials and space.

(Demarco & Lister, 1999, pp40,85,87)

people work better in natural light and with distant views to glance up to occasionally

(Demarco & Lister, 1999, pp42-43)

people only use after-hours time to get productive work done in the absence of interruptions and noise

(Demarco & Lister, 1999, pp44-50)

“Three rules of thumb seem to apply whenever you measure variations in performance over a sample of individuals:

• Count on the best people outperforming the worst by about 10:1.

• Count on the best performer being about 2.5 times better than the median performer.

• Count on the half that are better-than-median performers outdoing the other half by more than 2:1.

(Demarco & Lister, 1999, p52)

Demarco claims that there is no evidence that open-plan workspaces or corrals of uniformally set cubicles improve work productivity, and substantial evidence that such settings decrease productivity by great magnitudes

(Demarco & Lister, 1999, p53)

The McCue study done at IBM recommends 100 square feet of floor space and 30 square feet of table space per person, and sound proofing by offices or noise barriers

(Demarco & Lister, 1999, p62)

The McCue study found that developers need to spend 30% of their time in private work, 50% working with one other person and 20% working with more than two others.[DO11]

(Demarco & Lister, 1999, p63)

“During single-minded work time, people are ideally in a state that psychologists call flow”.

This state requires 15 minutes to lock in and is broken by any interruption.

(Demarco & Lister, 1999, p69)

turn off telephones, PAs, email reading, IM, skyping

(Demarco & Lister, 1999, p77)

objective is “an ignorable workspace” not a glitzy one

(Demarco & Lister, 1999, pp78-79)

listening to music is acceptable to let people flow with repetitive work, but not creative work, as music pre-occupies the right brain)

(Demarco & Lister, 1999, p86)

similar noises to the ones the person makes in their work do not interrupt

2.3.2 Provide the Right Community

Build a community. Vulnerability. Coooperation. Non-competition.

(Beck, 2004, p63)

jelled teams are apex performers, retain them intact

(Leffingwell, 2007, pp110-114)

High-performing agile teams have these characteristics:

“They have the right people on the team
They are led rather than managed
They understand their mission
They communicate and collaborate continuously
They are accountable for their results”

(Leffingwell, 2007, pp35-37) (Beck, 2004, pp17-22)

XP’s Core Values: vigorous communication, intentional simplicity, customer feedback, courage to learn, and respect for others limitations and needs

(Beck, 2004, pp23-34)

XP’s Core Principles: humanity of the involved, economic rationalism, mutual benefit long-term, looking for repeatability of technique, improvement rather than perfection, appreciation of diversity within the team, reflection on performance, continuous flow of value to the client, positivise problems into opportunities, employ systemic redundancy, as a safeguard, risk failure as a means to short-cut to success, velocity is not increased by decreasing quality, take “baby steps”, and responsibility is accepted rather than assigned.

(Leffingwell, 2007, pp35-37) (Beck, 2004, pp35-53)

XP’s Key Practices: the entire team sits together, a fully-skilled team, a task-informative workspace, energised work (intense 40 hour weeks), pair programming, task definition by “stories”, a weekly work iteration, a quarterly delivery to customers, slack is built in, the entire system should be able to be auto-built in ten minutes, all code changes are integrated into the system immediately, a failing test is written before the functioning code is written.

[DO12]

(Larman & Vodde, 2010, p31)

Avoid having a separate “test department”, integrate the task into the teams.

(Larman & Vodde, 2010, p34)

Try integrating the tester and technical writer function.[DO13]

(Larman & Vodde, 2010, p35)

Communities of Practice.

(Larman & Vodde, 2010, p51)

Have the product owner write the tests

(Larman & Vodde, 2010, pp104,146-147)

product owner meets with team (inward) and customers (outward) equally and maps their paradigms together

(Larman & Vodde, 2010, pp106-112)

avoid the “game” of contract negotiation between product management and development around scope and date,

(Fisher et al, 1991)

where people take “hard” and “soft” negotiation styles and negotiate on “position”, instead use “principled negotiation on mutual gains”.

(Larman & Vodde, 2010, p123)

Short term POs undermine this, can install a “fake” PO to kick-start the process

(Larman & Vodde, 2010, p148)

avoid having gurus who aren’t attached to any teams or customers

(Larman & Vodde, 2010, p128)

Overall PO can be the chief engineer and hence have a good overall balanced view of business and engineering needs

(Larman & Vodde, 2010, pp166-168)

allocate a pure research or pure infrastructure set of tasks to each team for a sprint occasionally[DO14]

(Larman & Vodde, 2010, pp171-179)

define and seek to expand the teams’ DoD, as to how many aspects of the business’ interest (coding, testing, documentation, performance testing, marketing material, training, pricing, etc) need to be covered off to define the team’s Sprint as complete.

(Larman & Vodde, 2010, pp191-193)

teams are selected and evolved to be typically able to respond concisely and thoroughly to specific types of feature additions, and so teams are allocated tasks that more suit them and they can deliver them efficiently.

(Larman & Vodde, 2010, p308)

architects code spikes

(Larman & Vodde, 2010, pp308-310)

Tiger teams used to hit the killer issues, write an implementation guideline when done for others to follow

(Larman & Vodde, 2010, p314)

teams undertake “show and tell” sessions where materials can benefit another team[DO15]

(Larman & Vodde, 2010, p386)

Avoid competitiveness, don’t use targets, rewards and KPIs[DO16]

(Larman & Vodde, 2010, p393)

don’t use an in-line manager or PO as Scrum Master

(Larman & Vodde, 2010, p409)

avoid performance-based rewards[DO17]

(Larman & Vodde, 2010, (p466)

long-lived teams

(Larman & Vodde, 2010, (pp467-468)

teams can say “no”

(Larman & Vodde, 2010, (p474)

experts coach and review rather than just design and hand-off

(Larman & Vodde, 2010, (p478)

avoid a “factory” mentality

(Beck, 2004, pp135-137)

Toyota Production System advocates integrating quality control at the point of creation of any item of work

(Beck, 2004, pp157-158)

Community is essential to foster cross-fertilisation and “enable questioning and doubt”

(Yourdan, 1996, pp43-44)

encourage special interest groups and staff involvement, provide mentoring

(Demarco & Lister, 1999, p8)

imposing a penalty for errors decreases learning and imagination and demotivates thought-workers

(Demarco & Lister, 1999, p9)

thought-workers are switched off by “the stick”

(Demarco & Lister, 1999, p11)

some people’s contribution is as the “jelling agent” that gets the team alive[DO18]

(Demarco & Lister, 1999, pp119-120)

“Hawthorne Effect” - any [non-threatening] change induces an increase in productivity through motivation by novelty[DO19]

(Demarco & Lister, 1999, pp122-128)

teams that jell together in shared success are orders of magnitude more productive and create their own momentum. The goals set for them should be their internal work-outcome goals, not the company-wide goals which are often distasteful and crass to them anyway. The manager’s task is to set these internal goals in line with the company’s overall goals (alignment), but without overdue reference to them

(Demarco & Lister, 1999, pp133-135)

things that will poison a team’s chances to jell are:

· lack of trust in the team

· over-prescriptive systems

· managerial defences

· low E-factors

· sacrificing product quality

· managing by dead-lines

· stifling team or personal individuality

· physically separating the team

(Demarco & Lister, 1999, p151)

the factors that help teams to jell:

“Make a cult of quality.
Provide lots of satisfying closure.
Build a sense of eliteness.[DO20]
Allow and encourage heterogeneity.
Preserve and protect successful teams.
Provide strategic but not tactical direction.”

(Demarco & Lister, 1999, p155)

as a manger, don’t attempt to break into your jelled team as a peer, just be their obstacle-clearer[DO21]

(Demarco & Lister, 1999, p160)

when a jelled team approaches a steady state, boredom is a risk – reintroduce disorder by: spiking technologies, training, trips, conferences, etc

(Demarco & Lister, 1999, p146,148)

show trust by reducing direct oversight, send the team on a conference or outing

(Demarco & Lister, 1999, p179-180)

overtime ends up getting unbalanced and incites jealousy

(Demarco & Lister, 1999, p181-184)

competition will inhibit team “jell”, as will performance reviews and rewards for individuals

2.3.3 Scaling the Environment

Single site, multisite and offshore

(Larman & Vodde, 2010, p194,198,200)

the team is responsible for their own coordination within the company and other teams, competition within and between teams is discouraged, representative members attend a “Scrum of Scrums” to coordinate and navigate feature addition collisions

(Larman & Vodde, 2010, p370)

most implementation of CI systems fail through organisational sociology problems

(Larman & Vodde, 2010, pp234-235)

don’t have overly specialist groups that deflect non-specialist responsibilities

(Demarco & Lister, 1999, p118)

achieve convergence of method across teams by use of training, common tools and peer reviews

(Demarco & Lister, 1999, p113-114)

mandating work systems methodologies removes the self-healing nature that is brought by human inclusion in the work-flow – people are familiar with the underlying goals and will correct the systemic errors on-the-fly

(Demarco & Lister, 1999, p116-117)

overdoing methodologies ends in abrogation of responsibility at the implementation level

2.4 Managing the Person

(Demarco & Lister, 1999, p108)
[indifference] towards turnover and staff value induces turnover and disengagement

(Demarco & Lister, 1999, p111-112)

companies with low turnover show high regard for staff value, but also a “preoccupation with being the best”, an reinvestment in staff, and an expectation that people will stay

2.4.1 Select the Person

Knowing what you are building – your company’s strategy.

Fit the people to the strategy.

Select the person – audition, test.

(Larman & Vodde, 2010, (p479)

interview by programming

(Beck, 2004, p82)

hire by having them work in the team for a day pair programming, tests technical and social skills

(Yourdan, 1996, pp37-38)

audition by giving a problem on the spot at the interview and asking them to solve it under supervision (advise about the process beforehand)[DO22]

(Demarco & Lister, 1999, p100)

audition prospective employees

(Demarco & Lister, 1999, p103-104)

aptitude tests for prospective employees only identifies their technical skill, you need to identify their sociological fit, invite his prospective peers to the audition, insist on a technical talk of relevance[DO23]

2.4.2 Develop the Person

Training, retention, planning Vulnerability.

(Yourdan, 1996, p50)

“have highly skilled people who are well managed and highly motivated”

(Larman & Vodde, 2010, pp56, 75)

Use A-TDD coaches, internal and external as required

(Larman & Vodde, 2010, p148)

POs should attend training on Agile methodology selected

(Larman & Vodde, 2010, p268)

learn and use a spectrum of analysis skills

(Larman & Vodde, 2010, p312)

architects teach during code reviews

(Larman & Vodde, 2010, p339)

schools, organisational support, self-study

(Larman & Vodde, 2010, p340)

“use your editor”[properly] is usually the most immediate gain available

(Larman & Vodde, 2010, pp341-342)

don’t trivialise programming – outsourcing, short-careers, salary depressions

(Larman & Vodde, 2010, p385)

learning by “infection”, maintain close contact with an Agile coach

(Larman & Vodde, 2010, p399)

external and internal agile coaches, structured training, stick with the methods tested and published recommendations

(Larman & Vodde, 2010, (pp468-469)

intensive coaching, buddying if high-attrition

(Beck, 2004, pp143-144)

use a coach

(Yourdan, 1993, p106)

CASE Research study reveals that “the typical software engineer needs between 1 to 2 years to become familiar and comfortable with a methodology”

(Yourdan, 1996, p33)

Taylorist arranged work is boring and disengaging

(Yourdan, 1996, p36)

let the software professionals decide their own training path, give them their own budget to spend[DO24]

(Demarco & Lister, 1999, pp20-21)

customers care less about internal quality than the author does

(Demarco & Lister, 1999, p22)

however permitting a builder to indulge in quality engages them, resulting in lower turnover and higher overall productivity

(Demarco & Lister, 1999, p24 -25

“Writing in 1954, the British author C. Northcote Parkinson introduced the notion that work expands to fill the time allocated for it, now known as Parkinson's Law. …

Parkinson's Law almost certainly doesn't apply to your people. Their lives are just too short for any loafing on the job. Since they enjoy their work, they are disinclined to let it drag on forever”

(Demarco & Lister, 1999, p103)

provide aptitude tests for internal staff as (safe) personal performance feedback

(Demarco & Lister, 1999, p177-178)

inspirational posters are demeaning to thought-workers[DO25]

2.4.3 The Person in a Scaling Context

Fear, change

(Yourdan, 1996, p160)

processes are not as crucial to the outcome as the talents and engagement of the people involved

(Yourdan, 1996, p167)

lack of care for the people will flow on to the results

(Demarco & Lister, 1999, pp13-19)

thought-workers put under pressure are going to work faster, not better, and then they’re going to be leaving with resentment

(Demarco & Lister, 1999, p20)

unattainable deadlines make people compromise quality, which strips their pride in their work and disengages them

(Demarco & Lister, 1999, pp26-29)

study done at the University of New South Wales showed that productivity is most enabled, from lowest to highest outcome by the work estimates being done by: the supervisor, the supervisor and the programmer, the programmer alone, a systems analyst, and best of all when no estimate is made at all

(Demarco & Lister, 1999, pp192-201)

people dislike and are resistant to change and respond emotionally to it, people need to feel safe, and that the new state will be a better one for them

(Demarco & Lister, 1999, p25)

underperformance is usually due to “lack of competence, lack of confidence, and lack of affiliation with others on the project and the project goals. In none of these cases is schedule pressure liable to help very much”

(Demarco & Lister, 1999, p26)

co-workers provide the best real performance pressure[DO26]

(Demarco & Lister, 1999, pp211-214)

protect and develop the middle mangers to be creative and feel safe, as they are the ideal locum of organisational change

(Demarco & Lister, 1999, pp215-219)

use meetings to resolve information gaps, not to establish power statuses

(Demarco & Lister, 1999, pp222-226)

a manager’s key job is to build a community that is self-activating[DO27]

2.4.4 Develop the Leader

You. Learning. Flexibility. Trust. Vulnerability.

(Beck, 2004, p57)

starting XP, change yourself first

(Yourdan, 1996, pp38-39)

determine why employees leave, turnover costs

(Brooks, 1975, p108)

managerial paperwork should be restrained to only a few deliberate documents useful in activating the business, and to avoid difficulties arising from misunderstandings in “common knowledge”

(Demarco & Lister, 1999, p1)

managers unwittingly tend to treat people as “modular components” because they come from technical backgrounds working with modular components

(Demarco & Lister, 1999, p4)

most mangers know they have people problems, but don’t manage as if so

(Demarco & Lister, 1999, p5)

managers prefer to manage non-people problems as it’s easier and safer for them

3 Evaluation Aspects

3.1 Aim of this Section

It is important to measure your success as you progress since many failures can result from unchecked progress.

3.2 Implementation Phases

Commit to being a “learning leader”.

Solicit commitment from any other influential parties.

(Larman & Vodde, 2010, pp157,162)

to introduce Agile, emphasise “continuous product improvement” and “partiality” rather than “project-based work” and “perfection”

(Larman & Vodde, 2010, pp273-276)

avoid application life-cycle management tools early, do it manually so that the process is understood – cards on walls, spreadsheets, wikis, RSS feeds; don’t use centralised tools – scattered Word documents on file systems, or even document tools like Lotus Notes or MS SharePoint

(Larman & Vodde, 2010, pp299-300)

have architects attached to a team as members, or lead regular technical workshops with teams

(Larman & Vodde, 2010, p304)

prototype in a different language deliberately to enforce “build one to throw away”[DO28]

(Larman & Vodde, 2010, p394)

two week iterations to enforce breaking the Waterfall habits[DO29]

(Larman & Vodde, 2010, p397)

introduce topic in big sessions to 200+ people at a time

(Larman & Vodde, 2010, p408)

disarm harmful entrenched practices or policies

(Beck, 2004, p95)

use stories on index cards on the wall, don’t IT it.[DO30]

(Beck, 2004, p108)

clean up ratty code as you go

(Beck, 2004, pp113-114)

introducing in an existing organisation, team’s external liaison needs to explain the activity well.

(Beck, 2004, p142)

conditions under which XP usually starts up successfully: strong value alignment by all, or a recovery from shared pain in the organisation

(Yourdan, 1996, p173)

most businesses have moved to becoming totally dependant on their IT systems, but still live in an expectation that IT is a trivial concern to them, and hence IT workers are of little consequence

(Larman & Vodde, 2010, p335)

emphasise benefit of transparency via partial progressive delivery, rather than fixed scope/date

3.3 Costs and Benefits

Costs include training time, decrease in unpaid overtime,

Benefits include increased productivity, reliable delivery, increased repeat business, improved workplace demeanour,

(Beck, 2004, p113)

capitalising versus expensing SD work

(Demarco & Lister, 1999, p202)

attempt to have software development and training accounted as capital, not expense, so as to have the investment in people recognised as such

(Beck, 2004, pp114-115)

durability of results over time improved by high degree of refactoring and test coverage

(Yourdan, 1996, pp32-33)

corporate profit is unrelated to their IT spend, Yourdan proposes that it is a function of their internal chemistry of “people, skill, motivation and technology”

(Yourdan, 1996, pp38-39)

rather than increase wage, give time off or luxury projects as a bonus

(Yourdan, 1996, pp157-181)

provide “good-enough” software

(Demarco & Lister, 1999, pp44-50)

“Three rules of thumb seem to apply whenever you measure variations in performance over a sample of individuals:

• Count on the best people outperforming the worst by about 10:1.

• Count on the best performer being about 2.5 times better than the median performer.

• Count on the half that are better-than-median performers outdoing the other half by more than 2:1.

Managing the working environment is one of the most immediately controllable factors able to directly influence the productivity of your thought-workers. The cost of the worker is estimated at 20 times the workspace cost, so the worker’s productivity is paramount over the workspace cost. (Demarco & Lister, 1999, p50-51)

3.4 Evaluation Criteria

Staff retention

Velocity

360 reviews

(Beck, 2004, pp23-34)

measuring XP team health by: defects found after development and the ROI lag (“investment to return”)

(Beck, 2004, p82)

either evaluate and reward by individual or team

(Beck, 2004, p139)

results from XP can take years to arrive

(Beck, 2004, p140)

XP teams misunderstood and sometimes laid off, because the standard corporate measures do not apply – working late and dramatically deploying large but broken code sets – work is undramatic, successful, gradual and in-hours

(Demarco & Lister, 1999, pp60-61)

provide a performance measurement mechanism for people that permits them to self-evaluate against the team, but is still anonymous, to retain self-esteem and sense of job-security.

(Demarco & Lister, 1999, p65)

track “flow” hours worked as a measure of internal productivity from effective environment management – “E-factor” percentage of time spent in “flow” over a week. Encourage people to find ways to get their “E-factor” up to 0.3 (30%) or above ..eg:

(Larman & Vodde, 2010, pp181-184)

teams estimate their “story points” and after a few iterations, you can measure their “velocity”, and move towards forecasting and tracking velocity

3.5 Summary

Manthey:

Waterfall requires a fully competent architect at the top, and obedient workers below, with mandatory upwards reporting and fragmented partial task setting downwards. The model is military in nature. Competition is rewarded with elevation. Momentum is embedded.

Agile is equally regimented, but competence and responsibility are distributed down into the worker layer. Cooperation is rewarded with innate business success. Agility is embedded.

(Brooks, 1975, pp120-123)

large systems built with Waterfall inevitably grind towards a slow death of unimprovability due to the massive maintenance cost in tracking regression bugs

4 Conclusions

(Larman & Vodde, 2010, p100)

‘lean thinking and agile principles are customer-focused for business success; they are not “development processes”’

(Demarco & Lister, 1999, p96)

it is extremely unlikely that you will change a person’s basic nature, but you can enable their performance through training and scene-setting

(Demarco & Lister, 1999, p171)

even one single major change to an organisation’s sociology is a huge achievement

5 Recommendations

(Larman & Vodde, 2010, p2)

Cargo cult

(Larman & Vodde, 2010, p4)

“There are no best practices – only adequate practices in context.”

(Larman & Vodde, 2010, p5)

The lure that there might be “fractal” practices is there, but is a false hope – scaling or transposing requires alterations to otherwise working practices.

(Larman & Vodde, 2010, pp374-381)

Adoption suggestions: emphasise people and interactions over processes and systems, ensure job security and personal respect, emphasise the principles and values of agile over the practices but don’t try to do agile without them, start slow, speed up and emphasise learning a lifestyle of agile rather than a project to “implement” it.

(Larman & Vodde, 2010, p391)

Gradual adoption by slow transition from component to feature teams, by introducing feature teams in parallel with component teams, some incompatibility. Recommended technique is “big bang” and accept the learning curve, although few companies are game to try this.

(Beck, 2004, p144)

killers of XP: culture of secrecy, isolation, complexity, timidity and disrespect

(Demarco & Lister, 1999, p210)

be a learning-oriented and adaptive organisation, and retain the investment in staff by working to reduce turnover

6 References

Ref	Details
(Leffingwell, 2007)	Leffingwell, D. (2007). Scaling Software Agility: Best Practices for Large Enterprises. Boston, MA: Addison-Wesley.
(Shine, 2003)	Shine Technologies. (2003). Agile Methodologies Survey Results. http://www.shinetech.com/attachments/104_ShineTechAgileSurvey2003-01-17.pdf
(Larman & Vodde, 2010)	Larman, C. & Vodde, B. (2010). Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Boston, MA: Addison-Wesley.
(Eckstein, 2004)	Eckstein, J. (2004). Agile Software Development in the Large: Diving Into the Deep. New York: Dorset House.
(Fisher et al, 1991)	Fisher, R, Ury, W & Patton, B. (1991). “Getting to Yes”: Negotiating Agreement Without Giving In (Second Ed). New York: Houghton Mifflin
(Beck, 2004)	Beck, K. & Andres, C. (2004). Extreme Programming Explained: Embrace Change. Boston, MA: Addison-Wesley.
(Demarco & Lister, 1999)	Demarco, T. & Lister, T. (1999). Peopleware: Productive Projects And Teams. town, STATE: Dorset House.
(Yourdan, 1996)	Yourdan, E. (1996). Rise and Resurrection of the American Programmer. Englewood Cliffs, NJ: Prentice-Hall.
(Yourdan, 1993)	Yourdan, E. (1993). Decline and Fall of the American Programmer. Englewood Cliffs, NJ: Prentice-Hall.
(Brooks, 1975)	Brooks, F.P. (1975). The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley.
(Gartner, 2010)	Gartner, M (2010). Markus Gärtner's blog: Software Testing, Craftsmanship, Leadership and beyond “Listen to the old ones, or re-invent the wheel.” http://blog.shino.de/2010/02/28/listen-to-the-old-ones-or-re-invent-the-wheel/

7 Off-topic citations

(Brooks, 1975, pp93-94)

programmers can produce a consistent number of debugged lines of code per year in virtually any language, so if the language in use is terse, you will get more business outcomes for your investment

(Brooks, 1975, pp115-123)

plan to throw one away

(Brooks, 1975, p116)

chemical plant will build a lab-prototype, then a “pilot plant” before committing to a full scale installation

(Brooks, 1975, p116)

[paraphrased] “You will build a prototype. The only choice is whether you throw it away, or deliver the throwaway to the customer.”

(Brooks, 1975, p118)

reluctance to document systems is principally a reluctance to having to defend partial solutions born on-the-fly and under pressure.

(Larman & Vodde, 2010, (p474)

avoid producing/employing the “four-year programmer”

(Brooks, 1975, pp53-58)

beware of the “second-system effect” – architects/programmers who are onto their second build and want to overdo it perfectly with obsolete technologies that they learnt on their first build.

(Demarco & Lister, 1999, p106-108)

average employee stays two years, has a short-term view of the work being done, so isn’t committed to the quality of outcomes or to leaving no legacy code, and may be working towards a management job as per the “fourth-year” programmer.

(Demarco & Lister, 1999, p207)

productive ramp-up time for a technology worker can be up to two years - turnover is extremely costly in these cases

[DO1]Sounds interesting to me. I can definitely identify with just that simple phrase although I suspect the actual reality is a hybrid of the two, i.e. attempting to design and build a living organism, which requires constant re-evaluation due to unforseen properties of the organism or the unforseen interactions between the organism and it’s changing environment. Plus the fact that organism has the ability to change the environment around it, and thus destablise any ecosystem that existed around it prior to it’s conception / implementation. (Woah heavy..)

[DO2]I think I would definitely like this Larman and Vodde book. Anyone who thinks this is a good idea is a moron – thankfully we didn’t have this problem at [deleted]…

[DO3]Nice to know my experiences haven’t been unique then…

[DO4]Which is proof enough that it’s broken – well kind of. “Ah yes, to build this particular system we recommend the waterfall approach to software development, but we do also recommend an agile prototyping phase prior to finalizing the project schedule and scope.”

I guess I should caveat what I say above, that in some particularly large projects that might actually be a really good model, as agile projects IMHO have a higher reliance on the intellectual investment from particular individuals and the longer the project, the higher the risk that you are going to lose people along the way. A risk management and good resource allocation strategy might be to put your best talent on prototyping and scope definition for a project, and then allocate the lower tiers of developers to implementation of the actual project implementation… maybe…

[DO5]Honestly, I’ve always thought this is a silly idea. But then again it’s not something I’ve actually tried. The idea of two smart productive people being limited to a single set of tools seems counter productive to me. I guess though that they guys taking care of the roadworks have effectively been doing pair digging (one shovel between two) for sometime and our roads manage to get built ;)

[DO6]Personal opinion, but not grounded in experience from [deleted], is that this is one of the more common sense agile development practices. I’m using it in my development at [deleted], but given it’s only me at this stage, I don’t really think my experience counts for much there. For what it’s worth, it’s working really well in providing a framework for customer interaction and managing expectations.

[DO7]Agreed – this should be incorporated into any project. I love front-loading the tricky stuff – definitely did that with the guys at [deleted]. If I’m going to get a surprise, then I prefer it closer to the start of the project…

[DO8]Good advice I think. Certainly from my own experience, it was always easier to hit a customer with a single set of dramatic schedule changes, rather than oh, yeah that’s going to be a couple more weeks. Being on the client end with some projects where the project is just a couple more weeks from completion really means that it’s just completely busted..

[DO9]Yep – critical.

[DO10]Which shows that it’s obviously a balancing act – and if you read some of Joel Spolsky’s thoughts I think he favours offices over open plan to ensure people have appropriate working conditions. Personally, I think I’d like to go for 70% open plan with no fixed desks (i.e. you have a laptop and sit to work wherever each day), and then have some breakout rooms for when you are doing the intense stuff where distractions just stuff you around big time…

[DO11]Cool, just read this after my previous comment. I think my floorspace allocation is about right then J

[DO12]My take on all this – love the core values and principles of XP and the Agile manifesto in general, but the actual practices and implementation of most agile programs seems pretty broken (as the discussion on the groups list you pointed me too looks).

Many, many parallels between successful software teams and small churches but the growing pains when someone attempts to document a successful formula. It’s noble but it really just never seems to work quite right..

[DO13]Great idea, one that I think I will definitely try when I get to a size that warrants that.

[DO14]Nice point also – I like J

[DO15]Tried to get this going at [deleted], and unfortunately it never really got that much momentum. Which I think points back to sociological issues as you said earlier..

[DO16]Yep – completely agree. If you haven’t already watched any of Dan Pink’s stuff from around the place, make sure you do. Definitely a good example in a TED session regarding the candle problem.

[DO17]As above.

[DO18]Make sure they have the goods as a coder though – I hired someone specifically for this purpose, but in the end they couldn’t code well enough to jell invigorate community in the development team.

[DO19]Must read up on this…

[DO20]This is potentially dangerous if you are building a company that will have incremental growth over time. It will be difficult for even talented newcomers to break in…

[DO21]Yep – completely agree. Probably one of the best pieces of advice for anyone who is transitioning off the tools into management.

[DO22]After reading a couple of posts on the topic of programmers who can’t program, I talked to the guy who took over from me in the dev team ([deleted]) and he has introduced a simple test called FizzBuzz. I believe it has prevented a few bad hiring decisions already J

[DO23]Cool idea.

[DO24]I like this approach – I think it will help motivate self-study also…

[DO25]LOL – absolutely. Unless they are suitably tongue in cheek – see some worth1000 competitions J

[DO26]Completely agree – and have witnessed this on multiple occasions. I’ve also seen that managers who attempt to take on this responsibility disengage the potential future leaders of the team by removing the opportunity for them to take on this responsibility…

[DO27]If only more people really believed in that, and we trained people to do it and demonstrated it was the best thing for their career many workplaces would be a better place.

[DO28]Nice – great way to encourage your people to learn new things and increase productivity through the Hawthorne effect which I just learnt about.

[DO29]Yep – I’m using Pivotal Tracker which is a great tool for doing this. Definitely need to catch up for a chat sometime…

[DO30]Interesting, not sure I agree with this one, but I definitely can agree that pen and paper is the appropriate domain for think-tanking thigs… Maybe another one for discussion.

--
You received this message because you are subscribed to the Google Groups "Brisbane XP" group.
To post to this group, send email to brisbane-xp@googlegroups.com.
To unsubscribe from this group, send email to brisbane-xp+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/brisbane-xp?hl=en.