Modules that require instantiation through a class function have the first letter in their name capitalised, in the same fashion as the class function name itself.
This tells the user that they should use the new keyword when calling the module, before gaining access to its methods.
MyModule.js
function MyClassFunction(param) {
var self = this;
// do stuff
}
module.exports = MyClassFunction;
usage:
var myObject = new (require('MyModule'))(param);
This naming convention focuses on usage rather than direct implementation. As such
Modules that have private class functions, called by static methods or wrapper functions, should begin with a lower case letter in their name.
myModule.js
function MyClassFunction(message) {
var self = this;
console.log('Instantiated private obj.');
};
MyClassFunction.staticMethod = function() {
var message = 'Called from static method';
return new MyClassFunction(message);
};
module.exports = {
myMethod: MyClassFunction.staticMethod
};
usage:
require('./myModule').myMethod();
Wednesday, August 3, 2011
Monday, August 1, 2011
Re-estimating stories during play - cone of uncertainty
Cone of uncertainty:
At time zero, we are at our maximum uncertainty about how a feature will be delivered. As we progress toward delivery, we learn more about the problem and hopefully its solution. As such, we are better equipped to provide increasingly accurate estimates as we approach delivery.
With this in mind, cases arise when stories need to be re-estimated after they're in play. I lean toward keeping the old estimate and recording the new estimate at the time it becomes obvious that the story is bigger/smaller than originally thought.
One of the questions often asked is whether we can defer re-estimation until after the story is delivered? This should be avoided for a few reasons:
At time zero, we are at our maximum uncertainty about how a feature will be delivered. As we progress toward delivery, we learn more about the problem and hopefully its solution. As such, we are better equipped to provide increasingly accurate estimates as we approach delivery.
With this in mind, cases arise when stories need to be re-estimated after they're in play. I lean toward keeping the old estimate and recording the new estimate at the time it becomes obvious that the story is bigger/smaller than originally thought.
One of the questions often asked is whether we can defer re-estimation until after the story is delivered? This should be avoided for a few reasons:
- We need to capture the number of times a story was re-estimated and why.
- Stories that have been re-estimated several times draw attention to themselves and should promote discussion about estimation, way the story has been broken down and other processes that support an iteration and velocity.
- Its important to encourage good estimation - avoiding re-estimation at the time it becomes obvious is counter productive to this goal. Further, several re-estimation attempts during a story is usually something a developer will try to avoid - it's a pride thing - as we inherently know this is bad.
During iteration planning and estimation, previous iteration stories, that underwent re-estimated, should be discussed before the team estimates new stories in an attempt to improve the estimation process.
Thursday, July 21, 2011
Self executing code in nodejs
Given that brackets against a function represent execute function:
var value = function blah(){return 'blah'}(); // evaluate value when called;
A nice way to start a web application with minimal start-up code is to wrap the execution of the start function in brackets - meaning execute this();
myWebApp.js:
var myWebApp = require('http');
(function start() {
function onRequest(req, res) {
res.writeHead(200, {"Content-Type": "text/plain"});
res.write("Congratulations! my web app is running.");
res.end();
}
myWebApp.createServer(onRequest).listen(8099);
console.log("Started MyWebApp ...");
}());
var value = function blah(){return 'blah'}(); // evaluate value when called;
A nice way to start a web application with minimal start-up code is to wrap the execution of the start function in brackets - meaning execute this();
myWebApp.js:
var myWebApp = require('http');
(function start() {
function onRequest(req, res) {
res.writeHead(200, {"Content-Type": "text/plain"});
res.write("Congratulations! my web app is running.");
res.end();
}
myWebApp.createServer(onRequest).listen(8099);
console.log("Started MyWebApp ...");
}());
Wednesday, January 26, 2011
Efficient recursion with Erlang
One of the stand-out sessions for me, at YOW_OZ 2010 Melbourne (Dec 2-3) was the talk Erlang warps your mind.
During the session, the presenter listed three hurdles to becoming an Erlang developer:
After looking around at a few Erlang tutorials, I found myself returning to sicp site to review its section on recursion optimisations. Basically, it all comes down to a rudimentary understanding of how execution processes utilise the humble stack to perform tasks.
The stack keeps tabs on the sequence in which instructions should be processed. When a function is called, the current instruction pointer is pushed onto the stack and a new stack for the called function is created, ready to sequence instructions to the process. Once the function returns a value, the stack is cleared an the previous instruction pointer is restored to continue execution. Imagine this as a tree of stacks, representing execution blocks, which point to child blocks when computational delegation is required to achieve the the blocks goal. These blocks wink in and out of existence, dependent upon execution completion and dependency counts.
Apply this knowledge to a recursive function:
(if (= n 1) 1
(* n (linear-factorial-recursion (- n 1))))
The multiplier on the last line, requires n and a recursive call to linear-factorial-recursion to evaluate and so the stack is retained until the entire function achieves its goal. We can imagine this evaluation like so:
(linear-factorial-recursion 3)
(* 3 (linear-factorial-recursion 2))
(* 3 (* 2 (linear-factorial-recursion 1)))
(* 3 (* 2 1))
(* 3 2)
= 6
As you can see, retaining a reference to achieve a full evaluation goal at the highest level, requires an expanding/Collapsible stack scenario, where the rate of expanse is proportional to the number of iterations - linear recursion - Imagine factorial 10000 - that's allot of stack space!!
To break the recursive dependency on the last line of the above function, one simply has to supply all state into the recursive function so that the calling function evaluates immediately, clearing the functions stack.
(define (iterative-factorial n) (tail-recursive-factorial 1 n))
(define (tail-recursive-factorial p n)
(if (= n 1) p
(tail-recursive-factorial (* p n) (- n 1))))
Notice that the last line is not assigned to a multiplier function, eliminating a reference to the calling function stack; Instead all state is evaluated as its passed into the recursive call to the function. We could imagine this evaluation like so:
(iterative-factorial 3)
(tail-recursive-factorial 1 3)
(tail-recursive-factorial 3 2)
(tail-recursive-factorial 6 1)
=6
Notice how the stack size remains constant, due to the fact that the previous function call passes all evaluated state to the new function call in an iterative linear fashion.
So some nice things about iterative linear recursion - or tail recursion:
Tail recursive factorial function in Erlang:
I'm using Scheme to explain recursion due to its predicate first syntax, which better lends itself to AST evaluation.
During the session, the presenter listed three hurdles to becoming an Erlang developer:
- Pattern Matching
- Recursion (Tail Recursion) and
- Concurrency
After looking around at a few Erlang tutorials, I found myself returning to sicp site to review its section on recursion optimisations. Basically, it all comes down to a rudimentary understanding of how execution processes utilise the humble stack to perform tasks.
The stack keeps tabs on the sequence in which instructions should be processed. When a function is called, the current instruction pointer is pushed onto the stack and a new stack for the called function is created, ready to sequence instructions to the process. Once the function returns a value, the stack is cleared an the previous instruction pointer is restored to continue execution. Imagine this as a tree of stacks, representing execution blocks, which point to child blocks when computational delegation is required to achieve the the blocks goal. These blocks wink in and out of existence, dependent upon execution completion and dependency counts.
Apply this knowledge to a recursive function:
(define linear-factorial-recursion n)
(if (= n 1) 1
(* n (linear-factorial-recursion (- n 1))))
The multiplier on the last line, requires n and a recursive call to linear-factorial-recursion to evaluate and so the stack is retained until the entire function achieves its goal. We can imagine this evaluation like so:
(linear-factorial-recursion 3)
(* 3 (linear-factorial-recursion 2))
(* 3 (* 2 (linear-factorial-recursion 1)))
(* 3 (* 2 1))
(* 3 2)
= 6
As you can see, retaining a reference to achieve a full evaluation goal at the highest level, requires an expanding/Collapsible stack scenario, where the rate of expanse is proportional to the number of iterations - linear recursion - Imagine factorial 10000 - that's allot of stack space!!
To break the recursive dependency on the last line of the above function, one simply has to supply all state into the recursive function so that the calling function evaluates immediately, clearing the functions stack.
(define (iterative-factorial n) (tail-recursive-factorial 1 n))
(define (tail-recursive-factorial p n)
(if (= n 1) p
(tail-recursive-factorial (* p n) (- n 1))))
Notice that the last line is not assigned to a multiplier function, eliminating a reference to the calling function stack; Instead all state is evaluated as its passed into the recursive call to the function. We could imagine this evaluation like so:
(iterative-factorial 3)
(tail-recursive-factorial 1 3)
(tail-recursive-factorial 3 2)
(tail-recursive-factorial 6 1)
=6
Notice how the stack size remains constant, due to the fact that the previous function call passes all evaluated state to the new function call in an iterative linear fashion.
So some nice things about iterative linear recursion - or tail recursion:
- The function can recurse indefinitely since stack resources are constant.
- Increase in performance as a result of less push pops for stacks
- parallelism due to orthogonal nature of recursive function calls. Stacks do not create child stack dependencies to achieve goals.
Tail recursive factorial function in Erlang:
-module(basic).
-compile(export_all).
factorial2(P, C) ->
if
C < 1 -> P;
true -> factorial2( P*C, C-1)
end.
factorial(N) -> basic:factorial2(1, N).
Tuesday, November 16, 2010
Configuring through Annotations - Death of DSL's
Traditionally, wiring of applications has been the domain of external DSL's. In the world of Java web applications, this is usually provided through XML. Examples of such DSL techniques are evident in many of today's major frameworks including Spring, Struts, Hibernate and iBatis.
Recently there has been a fundamental shift away from pure XML configuration, toward the use of Annotations where Spring is leading the charge. Spring is not alone, Hibernate also promotes the use of Annotations to describe persistable entities and their relationships. What results is a scattering of configuration markup throughout the code, and, as a result, domain objects, that now describe more than their atomic funtion - a mixing of concerns and so a violation of object oriented practices - namely the one that strongly suggests that an object only have one responsibility and therefore one reason to change (SRP). Further, this dilution of the XML DSL serves only to remove important concepts from the DSL, making it less complete and specific.
I'm not totally against annotations. I like the Annotations that replace marker interfaces - the ones used to mark key concepts like architectural layers - @Transaction, @Service, @Repository. In fact I prefer them to typical marker interfaces as they're extremely visible. The more visible a marker is, the better. Although, I'd prefer all marker annotations to come from the core java or jee libraries to reduce domain dependency on external frameworks. If this is not possible, roll your own.
Spring is by far the worst I've seen in this area. I recently wired an application together with a component-scan, a hibernate annotation aware bean and a transaction annotation aware bean - thats it!! That's crazy for all the wrong reasons. The config file isn't even a DSL anymore. It tells me nothing of what the application does or how it achieves it's purpose. It does tell me to trawl through the code, starting a base package, if I want details; Tim Veentjer blogs about similar experiences. What a bottom up approach! Advocates scream "It makes the Spring configuration clean". Actually its made the configuration irrelevant. Configuration is there to describe how your application achieves its purpose in some meaningful way that makes sense.
People who use the "It cleans up my application configuration" cry are really saying "I've pulled out too much detail in my configuration and often get confused with the correct level of abstraction." If you must pull everything out into the application configuration, put the noisy stuff that hides the intent of the application, in spring factories. If there is anything more than what you would use to describe your application in a five minute description - you have too much in there.
On that note, I use my application configuration file/s as a final refactoring aid to pin-point abstractions at the wrong level. Try it - you'll be amazed what you find - after you think you're done. Configuration DSL's are not something you use as a proverbial carpet to sweep crap under.
Jumping down to the code, the classes, particularly in the persistence layer become less readable; overly cluttered with perssistable annotations like @Table, @Column, @Id, @Constraint etc. What ever happend to domain objects not knowing anything about the environment beyond their immediate domain? Out of process markup is surely too much for a humble domain object to know about.
Recently there has been a fundamental shift away from pure XML configuration, toward the use of Annotations where Spring is leading the charge. Spring is not alone, Hibernate also promotes the use of Annotations to describe persistable entities and their relationships. What results is a scattering of configuration markup throughout the code, and, as a result, domain objects, that now describe more than their atomic funtion - a mixing of concerns and so a violation of object oriented practices - namely the one that strongly suggests that an object only have one responsibility and therefore one reason to change (SRP). Further, this dilution of the XML DSL serves only to remove important concepts from the DSL, making it less complete and specific.
I'm not totally against annotations. I like the Annotations that replace marker interfaces - the ones used to mark key concepts like architectural layers - @Transaction, @Service, @Repository. In fact I prefer them to typical marker interfaces as they're extremely visible. The more visible a marker is, the better. Although, I'd prefer all marker annotations to come from the core java or jee libraries to reduce domain dependency on external frameworks. If this is not possible, roll your own.
Spring is by far the worst I've seen in this area. I recently wired an application together with a component-scan, a hibernate annotation aware bean and a transaction annotation aware bean - thats it!! That's crazy for all the wrong reasons. The config file isn't even a DSL anymore. It tells me nothing of what the application does or how it achieves it's purpose. It does tell me to trawl through the code, starting a base package, if I want details; Tim Veentjer blogs about similar experiences. What a bottom up approach! Advocates scream "It makes the Spring configuration clean". Actually its made the configuration irrelevant. Configuration is there to describe how your application achieves its purpose in some meaningful way that makes sense.
Actually its made the configuration irrelevant.
People who use the "It cleans up my application configuration" cry are really saying "I've pulled out too much detail in my configuration and often get confused with the correct level of abstraction." If you must pull everything out into the application configuration, put the noisy stuff that hides the intent of the application, in spring factories. If there is anything more than what you would use to describe your application in a five minute description - you have too much in there.
On that note, I use my application configuration file/s as a final refactoring aid to pin-point abstractions at the wrong level. Try it - you'll be amazed what you find - after you think you're done. Configuration DSL's are not something you use as a proverbial carpet to sweep crap under.
Jumping down to the code, the classes, particularly in the persistence layer become less readable; overly cluttered with perssistable annotations like @Table, @Column, @Id, @Constraint etc. What ever happend to domain objects not knowing anything about the environment beyond their immediate domain? Out of process markup is surely too much for a humble domain object to know about.
Sunday, August 3, 2008
Builder's shouldn't mix
Those few who have read my past posts, may have noticed my preference for the use of builder style methods, which look something like this:
I like the expressiveness the builder style method gives me; Bringing me closer to chaining methods that resembled sentences.
While I like the way the above line reads, it's not enough to endorse their use any longer ... and here's why.
Publisher is a concept and like all good concepts, its definition is defined through an interface (or abstract class, but most likely an interface). If I was to look at this Interface, I'd see something like the following:
Alternatively, I could have tacked the methods together differently:
What I dislike is that information about sequence of calls is only discernible in the implementation of our Publisher's behavior. That's an abstraction lower than I should have to go when reading clear, written code. The interface gives no clue.
One could argue the case, "Oh but anything that returns an instance of itself would be called first ... blah, blah, blah"; But, the fact still remains - One can't be sure by simply looking at the method signatures - and that extra trip to an implementation is a trip I'd rather not make if I didn't have to.
So what was the publisher refactored to?
After looking at an implementation, it was found that the publisher is created with a default output stream and if one is not provided at the time of publishing, the publisher defaults to the output stream created at its time of construction.
A middle ground was struck that didn't read quite as well as the first attempt, but provided an interface which told a better version of the truth than its predecessor.
To publish to the default output stream: publisher.publish(aPublishableItem);
To publish to a given output stream: publisher.publish(aPublishableItem, outputStream);
In summing up, I chose to favor clarity of type behavior, for developers who may want to use the Publisher type in future, over a nice sentence, for readers of existing code. In this case the trade-off is subtle, as the refactored code is still quite readable. What's important is that I value both readers of my code and users of my types. In doing so I try to satisfy both sides in a reasonable way. In this example, I felt that users of my type were unfairly disadvantaged to satisfy a really nice sentence like chaining of behavior.
publisher.uses(anOutputStream).toPublish(aPublishableItem);
I like the expressiveness the builder style method gives me; Bringing me closer to chaining methods that resembled sentences.
While I like the way the above line reads, it's not enough to endorse their use any longer ... and here's why.
Publisher is a concept and like all good concepts, its definition is defined through an interface (or abstract class, but most likely an interface). If I was to look at this Interface, I'd see something like the following:
public interface Publisher
{
void toPublish(PublishableItem aPublishableItem);
Publisher uses(OutputStream outputStream);
}
The first thing that stands out is the uses builder method that takes an output stream and uses it in some fashion.
"What's so bad about that?" I hear you ask.
Let's assume I was not the author of this interface or any of its implementations. I would have to read the implementation to understand how this type was used. Or, more precisely, what sequence behavior should be called in, when required.
So it's possible that sequence of calls is very important. For instance (pardon the pun)
publisher.uses(anOutputStream).toPublish(aPublishableItem);
Could publish the publishable item to the passed in output stream.
Alternatively, I could have tacked the methods together differently:
publisher.toPublish(aPublishableItem);
publisher.uses(anOutputStream);
Might publish the publishable item to a default output stream and nothing to the passed in output stream.
What I dislike is that information about sequence of calls is only discernible in the implementation of our Publisher's behavior. That's an abstraction lower than I should have to go when reading clear, written code. The interface gives no clue.
One could argue the case, "Oh but anything that returns an instance of itself would be called first ... blah, blah, blah"; But, the fact still remains - One can't be sure by simply looking at the method signatures - and that extra trip to an implementation is a trip I'd rather not make if I didn't have to.
So what was the publisher refactored to?
After looking at an implementation, it was found that the publisher is created with a default output stream and if one is not provided at the time of publishing, the publisher defaults to the output stream created at its time of construction.
A middle ground was struck that didn't read quite as well as the first attempt, but provided an interface which told a better version of the truth than its predecessor.
To publish to the default output stream: publisher.publish(aPublishableItem);
To publish to a given output stream: publisher.publish(aPublishableItem, outputStream);
In summing up, I chose to favor clarity of type behavior, for developers who may want to use the Publisher type in future, over a nice sentence, for readers of existing code. In this case the trade-off is subtle, as the refactored code is still quite readable. What's important is that I value both readers of my code and users of my types. In doing so I try to satisfy both sides in a reasonable way. In this example, I felt that users of my type were unfairly disadvantaged to satisfy a really nice sentence like chaining of behavior.
Wednesday, July 9, 2008
Selfish Development
I think one of the main reasons we, as developers, start programming is to express ourselves creatively. It's the creative process that keeps us coming back for more: There is nothing more rewarding than distilling down a seemingly complex problem to a simple solution. This doesn't need to happen in the code first. The reward usually happens much earlier during the discussion about the problem with your team members (fellow developers, analysts, customers etc).
Of course this is true in any field. Oliver Wendell Holmes Jr. (1841 -1935) Once said "I wouldn't give a fig for the simplicity on this side of complexity; I would give my right arm for the simplicity on the far side of complexity". If he was talking about software development, I believe he would be saying that it's not enough to solve the problem. We need to solve problems in ways that other people can understand and use.
As a developer this means writing code that's explicit about your intent. In Bob Martin's words, "The name of a variable, function or class should answer all the big questions. It should tell you why it exists, what it does and how it's used". Eric Meyer sees it as trying to tell as much truth about your intent as possible. You can't tell the whole truth, due to the nature of abstraction, but you must try. Doing so will help you avoid the over abstraction syndrome that plagues source code (Over abstraction occurs when important information is abstracted away too early, requiring the reader to divert down a side path to understand the solution). I'll talk more on this in a coming post as it requires a discussion of encapsulation and cohesion.
So what does this have to do with selfish development? Put simply it is this - If you are worth your money as a developer, your code will be read many times and there's a cost to reading and understanding code. So good code is easy to read and understand. If its easy to read and understand then its more than likely easy to extend. It also needs to be correct in a manner that can be proven when required. This provides confidence to you and those who will use or maintain the code in future. So it needs automated tests and excellent (not good) coverage. With this in mind, team members should avoid writing dirty, untested code under the premise of - "I just need to get something out. We can come back and clean it up later"; or my favorite, "I'll get it working and you can make it pretty". What's actually being said is, "I'm too lazy to do a proper job but I want to enjoy being creative. You can deal with my stuff once it works (do maintenance). Oh and don't ask me to explain how it works. I'm not good at explaining things".
It's of no difference if you're a team of one or many; Pairing or flying solo; It's not done until it works, is testable and understandable.
One of the "tells" of this process is someone who wants to provide a solution in a technology before they understand or have defined the problem (bottom-up programmers): The implementation nuts, who are crazy about the latest api or library out there. It's like a person who needs to hang a picture on the wall. Straight away s/he runs out, grabs a nail and a hammer and starts banging. Unfortunately, the picture must be hung in a specific area and a reinforced steel girder occupies that area. Our friend keeps banging away, saying "hang on, I've almost got it" ... you can see where this is going.
The alternative is to talk about the problem; Code by intention; top-down; Write the class or function that answers "Wouldn't it be cool if I had an object that did..." and worry about the implementation afterward. While your at it, you might as well test using Test Driven Development (TDD). Doing so requires you to understand the problem you need to solve before you try to solve it with the detail (take a squiz at testing with mocks, interfaces and abstracts). It also allows you to concentrate on defining the problem in an abstract easy to understand way before getting into the noisy detail of exactly what you will use to provide the solution.
My personal experience is that a well defined, high level solution to a problem, written in the conceptual layer, leads to less coupling in your system allowing you to dangle implementation details off you abstractions, one at a time. For complex systems, it's much easier to understand a small bit of implementation detail, trusting that the system is correctly communicating among its components to solve the greater problem, than to think of everything at once (the details and how its going to communicate with other parts of the system).
I've worked with people who have criticized other developers because they talk about the problem too much before putting something down. Personally, I like these guys, they use the best computer, our brains, which are largely configured to quickly compile and optimise language, before proceeding to the more expensive writing of code. Refactoring helps but is no match for an open discussion about the problem and how to simplify it among people.
One further comment: I was careful in my post to use developer and programmer in specific places. I believe a programmer is someone who knows how to solve a problem with a given language or api without regard for the true elegance required in a well designed system that is very easy to understand and change. A developer is something again. S/he is someone who is considerate to the users of the code base, customers and other developers. In doing so, they seek clarity of intent and elegance in design of a maintainable system. They have values (I'll rant about this in a future post), principles and tested practices. They can justify their values and principles and constantly test their practices. aahhh, this is getting a little to zen.
Stepping down from my high horse: Before I was a developer, I was a programmer. I've been guilty of everything I've spoken of in the negative. I try to improve the readabilty of my code, with every line I write, leaving in a better state than I found it. My success varies, but over time I'm improving ... I have a long way to go. I would appreciate your comment.
Of course this is true in any field. Oliver Wendell Holmes Jr. (1841 -1935) Once said "I wouldn't give a fig for the simplicity on this side of complexity; I would give my right arm for the simplicity on the far side of complexity". If he was talking about software development, I believe he would be saying that it's not enough to solve the problem. We need to solve problems in ways that other people can understand and use.
As a developer this means writing code that's explicit about your intent. In Bob Martin's words, "The name of a variable, function or class should answer all the big questions. It should tell you why it exists, what it does and how it's used". Eric Meyer sees it as trying to tell as much truth about your intent as possible. You can't tell the whole truth, due to the nature of abstraction, but you must try. Doing so will help you avoid the over abstraction syndrome that plagues source code (Over abstraction occurs when important information is abstracted away too early, requiring the reader to divert down a side path to understand the solution). I'll talk more on this in a coming post as it requires a discussion of encapsulation and cohesion.
So what does this have to do with selfish development? Put simply it is this - If you are worth your money as a developer, your code will be read many times and there's a cost to reading and understanding code. So good code is easy to read and understand. If its easy to read and understand then its more than likely easy to extend. It also needs to be correct in a manner that can be proven when required. This provides confidence to you and those who will use or maintain the code in future. So it needs automated tests and excellent (not good) coverage. With this in mind, team members should avoid writing dirty, untested code under the premise of - "I just need to get something out. We can come back and clean it up later"; or my favorite, "I'll get it working and you can make it pretty". What's actually being said is, "I'm too lazy to do a proper job but I want to enjoy being creative. You can deal with my stuff once it works (do maintenance). Oh and don't ask me to explain how it works. I'm not good at explaining things".
It's of no difference if you're a team of one or many; Pairing or flying solo; It's not done until it works, is testable and understandable.
One of the "tells" of this process is someone who wants to provide a solution in a technology before they understand or have defined the problem (bottom-up programmers): The implementation nuts, who are crazy about the latest api or library out there. It's like a person who needs to hang a picture on the wall. Straight away s/he runs out, grabs a nail and a hammer and starts banging. Unfortunately, the picture must be hung in a specific area and a reinforced steel girder occupies that area. Our friend keeps banging away, saying "hang on, I've almost got it" ... you can see where this is going.
The alternative is to talk about the problem; Code by intention; top-down; Write the class or function that answers "Wouldn't it be cool if I had an object that did..." and worry about the implementation afterward. While your at it, you might as well test using Test Driven Development (TDD). Doing so requires you to understand the problem you need to solve before you try to solve it with the detail (take a squiz at testing with mocks, interfaces and abstracts). It also allows you to concentrate on defining the problem in an abstract easy to understand way before getting into the noisy detail of exactly what you will use to provide the solution.
My personal experience is that a well defined, high level solution to a problem, written in the conceptual layer, leads to less coupling in your system allowing you to dangle implementation details off you abstractions, one at a time. For complex systems, it's much easier to understand a small bit of implementation detail, trusting that the system is correctly communicating among its components to solve the greater problem, than to think of everything at once (the details and how its going to communicate with other parts of the system).
I've worked with people who have criticized other developers because they talk about the problem too much before putting something down. Personally, I like these guys, they use the best computer, our brains, which are largely configured to quickly compile and optimise language, before proceeding to the more expensive writing of code. Refactoring helps but is no match for an open discussion about the problem and how to simplify it among people.
One further comment: I was careful in my post to use developer and programmer in specific places. I believe a programmer is someone who knows how to solve a problem with a given language or api without regard for the true elegance required in a well designed system that is very easy to understand and change. A developer is something again. S/he is someone who is considerate to the users of the code base, customers and other developers. In doing so, they seek clarity of intent and elegance in design of a maintainable system. They have values (I'll rant about this in a future post), principles and tested practices. They can justify their values and principles and constantly test their practices. aahhh, this is getting a little to zen.
Stepping down from my high horse: Before I was a developer, I was a programmer. I've been guilty of everything I've spoken of in the negative. I try to improve the readabilty of my code, with every line I write, leaving in a better state than I found it. My success varies, but over time I'm improving ... I have a long way to go. I would appreciate your comment.
Sunday, August 12, 2007
Conceptual Integrity
Conceptual integrity of your software solution is arguably one of the more important factors to focus on, increasing understandability, maintainability etc.
One way to maintain conceptual integrity is to apply the Domain Pattern. Two good resources covering Domain Driven Design (DDD) are:
• Domain Driven Design, Eric Evans 2004
• Applying Domain-Driven Design and Patterns, Jimmy Nilsson 2006
An application’s conceptual language takes centre stage in DDD, allowing business owners and developers to talk the same language. A clear, simple conceptual language shortens the divide between business analysts and developers, during their feature discovery cycles.
I can’t stress enough: Good software is all about good communication. Agreement between project stakeholders, to work toward a simple conceptual language modelling real-world processes will improve the project's chances of success.
Maximise understandability by minimising overloaded meaning.
If there is more than one word or phrase to describe a process, try one of the following:
Step 12 in “The Joel Test”, which documents 12 steps to better code, asks if you do hallway usability testing. I feel this testing is really challenging your Domain Model using your conceptual language.
Continually test your domain model's power, flexibility, complexity and conceptual integrity:
This is my way of hallway testing…as a spontaneous design session. Don't be afraid to put your domain model, or parts of it, on the wall for all to see. Put post-it notes on the model with questions you expect the model to answer (i.e. Can user x searh all assets owned by business unit y?). Encourage others to comment, question and amend through this shared process.
Remember, the more "cold" eyes on a problem area, the better chances that problem has of being resolved properly.
One way to maintain conceptual integrity is to apply the Domain Pattern. Two good resources covering Domain Driven Design (DDD) are:
• Domain Driven Design, Eric Evans 2004
• Applying Domain-Driven Design and Patterns, Jimmy Nilsson 2006
An application’s conceptual language takes centre stage in DDD, allowing business owners and developers to talk the same language. A clear, simple conceptual language shortens the divide between business analysts and developers, during their feature discovery cycles.
I can’t stress enough: Good software is all about good communication. Agreement between project stakeholders, to work toward a simple conceptual language modelling real-world processes will improve the project's chances of success.
Maximise understandability by minimising overloaded meaning.
If there is more than one word or phrase to describe a process, try one of the following:
- Look for a more specific word, that narrows meaning. "Entity" is a pet hate of mine. Seriously, unless accompanied by a domain specific context, get rid of it. Substitute it for "Thingy" - at least it will scream attention as you increase domain fidelity.
- Agree to use one word and actively ensure all conversation participants support the decision. This decision should come from the business owners.
- When neither word suitably describes the overloaded meaning, the issue is usually one of context. Extract the contextual meanings and distill into one description for each context. Agree on a single abstract word for the original overloaded word. The abstracted word and one of the context descriptors will then be used to narrow meaning in the domain.
Step 12 in “The Joel Test”, which documents 12 steps to better code, asks if you do hallway usability testing. I feel this testing is really challenging your Domain Model using your conceptual language.
Continually test your domain model's power, flexibility, complexity and conceptual integrity:
- Can it answer a question required for your next iteration?
- Is the answer way to complex or a little vague?
- Are there several ways to answer the question, and if so, is it an early indicator of a domain model or conceptual language smell?
This is my way of hallway testing…as a spontaneous design session. Don't be afraid to put your domain model, or parts of it, on the wall for all to see. Put post-it notes on the model with questions you expect the model to answer (i.e. Can user x searh all assets owned by business unit y?). Encourage others to comment, question and amend through this shared process.
Remember, the more "cold" eyes on a problem area, the better chances that problem has of being resolved properly.
Thursday, December 28, 2006
Work Life Balance and Worry
Today I had lunch with a friend, who mentioned this blog. I thought it was time to make another entry and dump something I'm grappling with at the moment....
Since accepting a management position, I've found myself in constant battle maintaining a work to life balance.
Some things I worried about:
You get the idea … I've tied worry to life balance bacause I find that even when not at work, its easy to take home the worries of the day.
So here are some early tools I’ve found to maintain balance and combat worry:
1. The first is a quote by Brian Dyson (CEO: Coca-Cola) on life balance. I use it when making those work or family decisions (when it always seems to be work):
2. Having a plan of action returns the power to you. Answer the following questions empowers you.
3. Process for dealing with problems and worry at work from Dale Carnegie's "How to stop worrying and start living":
Since accepting a management position, I've found myself in constant battle maintaining a work to life balance.
Some things I worried about:
- How to keep my team happy and provide adequate service.
- How to keep my clients happy and in doing so maintain or improve my company's reputation.
- How to make time for my partner
- How to set myself up for family and by that I mean - not progressing down a path where work consumes late nights and weekends. I want my kids to know me and I want to love and experience as much of their growth as possible.
You get the idea … I've tied worry to life balance bacause I find that even when not at work, its easy to take home the worries of the day.
So here are some early tools I’ve found to maintain balance and combat worry:
1. The first is a quote by Brian Dyson (CEO: Coca-Cola) on life balance. I use it when making those work or family decisions (when it always seems to be work):
“Imagine life as a game in which you are juggling some five balls in the air – work, family, health, friends and spirit – and you’re keeping all of these in the air. You will soon understand that work is the rubber ball. If you drop it, it will bounce back. But the other four balls – family, health, friends and spirit – are made of glass. If you drop one of these, they will be irrevocably scuffed, marked, nicked, damaged or even shattered. They will never be the same. You must understand that and strive for balance in your life”
2. Having a plan of action returns the power to you. Answer the following questions empowers you.
- Whats the worst that could happen?
- Accept the worst as an outcome?
- Devise a plan to improve on the accepted outcome?
3. Process for dealing with problems and worry at work from Dale Carnegie's "How to stop worrying and start living":
- Write down a clear problem statement - What am i worrying about?
- Take time to collect facts about the problem
- List all solutions and their probable consequences - What can i do about it?
- Strive to keep emotion out of thinking for solving problems
- Pretend you're impartial, collecting information for someone else.
- List all possible outcomes against and for each solution
- Choose the best problem solution
- Action the problem solution - do something about it.
- At this point, stop thinking about worrying about the consequences. The time for thinking has past and its time to commit to action.
Subscribe to:
Posts (Atom)