Ron Jeffries of XP fame:

“If I’ve got six months to build a system, then I’ll spend six months building it. I’ll also spend six months designing it, and another six months testing it. The good news is that it’s the same six months”.

Seems like the best (and obvious) thing, right? Build the design based on your knowledge, which you acquire as you work on the project and encounter problems and design choices.

But begs the question: Is there a place for an Architect in an Agile environment and is there any value in an architecture document?

An architecture document is a system design that answers key design problems and breaks the system down into manageable and extensible components. I’ve worked on big arch documents in the past when working in waterfall environments – looking back, it’s easy to see that we spent a lot of time agonizing over design decisions that couldn’t be properly answered until much of the code was written. So continuous design is good.

But how do you document it in a continuous fashion? We used to create Word documents but that seems like too much work if you are going to be changing it often as you will be re-arranging the document all the time. A Wiki? Some bespoke Agile tool? UML tool?

Or do you not document it at all? Is Javadoc (or your language’s equivalent) enough along with some auto-generated class diagrams? Perhaps the test cases will document the functions of the system and avoid the need for Sequence diagrams? After all, once the code is done, the tests pass and the system is released, what’s the architecture design document for? It can only be a reference tool for people coming onto the project later on.

Many people have said that an Agile design document should have “Just enough in it to get the job done”. Great in theory but a tough one to do – what’s just enough?

If it’s not the coolest then it’s definitely the geekiest:

http://www.jwz.org/

I was visiting my parents with my daughter last weekend – I was on holiday from work at the time. As we were leaving I had to open the boot of my car to get something out and my Mum spotted an old 68000 assembler book that had been lying in there for manyyears.

“You’re not reading work stuff while you are on holiday are you?” she said.

“No”, I replied, “That’s not a work book, I read those for fun”.

“Oh…….”, there was a slight pause and a worried look from Mum, “I didn’t realise you were that weird”.

Thanks Mum.

Does software development have to be difficult? In my experience the answer is usually yes – only one of the places I have worked had a development process that worked well.

Software engineering is quite a young discipline and we’re still learning how to best do it.

We have different models like Waterfall, V Model and Agile – and then we have the great anti-model: cowboy coding. Waterfall, V and Agile all have their strengths and weaknesses, they can all be put to good use on the right project with the right team.

Regardless of which model you use there are some sure fire ways to make sure your software project is as difficult and painful as possible for everyone:

• Don’t use source control – All those branches and tags are just meaningless. What’s wrong with a shared directory anyway?
• Ain’t got time to unit test – Unit testing is just something you do at the end of a coding task if, and only if, you’ve got time. We’ve got a test team who test our software anyway.
• Don’t specify – The people defining what the software must do don’t have time to write anything down or talk the coders through the details – people should know what they want.
• Don’t design – Diagrams and design documents are for n00bs. Just get on with the code, things’ll get done quicker that way.
• We’re all individuals – Don’t let your programmers waste time telling their peers what they are working on or asking for their advice or ideas. They have their own work to do. You don’t have time to share.
• Users know nothing – The users don’t know what they want. Never ask them. The programmers know best.
• Test team just pick faults – The test team are evil. Do not trust them. They spend their life picking faults in your code and they love it, love it.
• Pick a ship date – Pluck a go-live date out of your ass and let your team know. Stick to it and never ever move it, no matter what happens. Do not ask the team for their work estimates – they are always wrong.
• Re-invent the wheel – Don’t use open-source or any other solution on the market for your project – you need to write everything from scratch to make sure it’s yours.
• Don’t use Java – It is slow and it sucks.

Not sure why I found it funny, but I did. Was reading Stack Overflow today and someone had asked a question about managing an object pool. One answer was, “use the Multiton pattern”.

Has a design pattern ever sounded more like a character from Pokemon?

Even though it has a comedy name it does have a legitimate use – whereas a Singleton holds once instance of an object a Multiton holds a specified number and thus creates an object pool. Wikipedia has an example.

Project Euler is a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve. Although mathematics will help you arrive at elegant and efficient methods, the use of a computer and programming skills will be required to solve most problems.

The motivation for starting Project Euler, and its continuation, is to provide a platform for the inquiring mind to delve into unfamiliar areas and learn new concepts in a fun and recreational context.

http://projecteuler.net/index.php?section=about 

0 = Success
1 = Operation not permitted
2 = No such file or directory
3 = No such process
4 = Interrupted system call
5 = Input/output error
6 = No such device or address
7 = Argument list too long
8 = Exec format error
9 = Bad file descriptor
10 = No child processes
11 = Resource temporarily unavailable
12 = Cannot allocate memory
13 = Permission denied
14 = Bad address
15 = Block device required
16 = Device or resource busy
17 = File exists
18 = Invalid cross-device link
19 = No such device
20 = Not a directory
21 = Is a directory
22 = Invalid argument
23 = Too many open files in system
24 = Too many open files
25 = Inappropriate ioctl for device
26 = Text file busy
27 = File too large
28 = No space left on device
29 = Illegal seek
30 = Read-only file system
31 = Too many links
32 = Broken pipe
33 = Numerical argument out of domain
34 = Numerical result out of range
35 = Resource deadlock avoided
36 = File name too long
37 = No locks available
38 = Function not implemented
39 = Directory not empty
40 = Too many levels of symbolic links
41 = Unknown error 41
42 = No message of desired type
43 = Identifier removed
44 = Channel number out of range
45 = Level 2 not synchronized
46 = Level 3 halted
47 = Level 3 reset
48 = Link number out of range
49 = Protocol driver not attached
50 = No CSI structure available
51 = Level 2 halted
52 = Invalid exchange
53 = Invalid request descriptor
54 = Exchange full
55 = No anode
56 = Invalid request code
57 = Invalid slot
58 = Unknown error 58
59 = Bad font file format
60 = Device not a stream
61 = No data available
62 = Timer expired
63 = Out of streams resources
64 = Machine is not on the network
65 = Package not installed
66 = Object is remote
67 = Link has been severed
68 = Advertise error
69 = Srmount error
70 = Communication error on send
71 = Protocol error
72 = Multihop attempted
73 = RFS specific error
74 = Bad message
75 = Value too large for defined data type
76 = Name not unique on network
77 = File descriptor in bad state
78 = Remote address changed
79 = Can not access a needed shared library
80 = Accessing a corrupted shared library
81 = .lib section in a.out corrupted
82 = Attempting to link in too many shared libraries
83 = Cannot exec a shared library directly
84 = Invalid or incomplete multibyte or wide character
85 = Interrupted system call should be restarted
86 = Streams pipe error
87 = Too many users
88 = Socket operation on non-socket
89 = Destination address required
90 = Message too long
91 = Protocol wrong type for socket
92 = Protocol not available
93 = Protocol not supported
94 = Socket type not supported
95 = Operation not supported
96 = Protocol family not supported
97 = Address family not supported by protocol
98 = Address already in use
99 = Cannot assign requested address
100 = Network is down
101 = Network is unreachable
102 = Network dropped connection on reset
103 = Software caused connection abort
104 = Connection reset by peer
105 = No buffer space available
106 = Transport endpoint is already connected
107 = Transport endpoint is not connected
108 = Cannot send after transport endpoint shutdown
109 = Too many references: cannot splice
110 = Connection timed out
111 = Connection refused
112 = Host is down
113 = No route to host
114 = Operation already in progress
115 = Operation now in progress
116 = Stale NFS file handle
117 = Structure needs cleaning
118 = Not a XENIX named type file
119 = No XENIX semaphores available
120 = Is a named type file
121 = Remote I/O error
122 = Disk quota exceeded
123 = No medium found
124 = Wrong medium type

Any piece of development, be it a full-blown system or a small 20-line change, is measured by people on two things, and two things only:

• Was it delivered on time?
• Does it work?

Your programming peers and other tech types might be impressed that you used some design patterns to create a modular, re-usable approach. They might love that new library or widget you found and are now using. They might think your source-code is immaculate – if there was a museum of fine programming pieces then this’d be in it.

The stakeholders don’t care about that stuff. The project manager doesn’t care. The product manager doesn’t care. The users don’t care. The people managing the budget don’t care. They want your software to work and they want it when they asked for it.

If I’m having a bad day at work there is one website that will always cheer me up: The Daily WTF. It’s full of techy humour and never fails to raise a laugh. These two code snippets are from here, you have to be a developer to appreciate these:

void failIfNull(Object o) throws RuntimeException {
  if (o == null)
  {
    throw new RuntimeException(o.getClass().getName() + " is null!");
  }
}

and…..

// An exception may be thrown before the [...] is fully initialised
if (this.equals(null))
{
  Warning.showWarning((JFrame) null, title, msg);
}
else
{
  Warning.showWarning(this, title, msg);
}