It's sometimes hard for developers to remember that table structure is also an API. Yes, it should be considered an internal API for the application you are developing, but it is still part of a system that must be carefully constructed to reflect the reality in which it operates. It is not enough to just normalize data following the rules of database normalization... not anymore anyway... it is important to consider how you will mash-up and add onto a database schema.
Consider RESTful webservices as a unique opportunity to add data into an enterprise system. You have a URI for a resource exposed by a restful API. That URI can then be bookmarked and annotated in a system like del.icio.us for your internal users.
That kind of annotation is powerful. It means you can add tags, wiki, and annotated information to CRM pages, BOM, or other data independent of the underlying system implementation. And, not surprizingly, Grails is well situated for this. Grails projects with Content Negotation can be viewed as amazing polymorphic services that display web pages to browsers, XML to services, and JSON to ajax clients.
That flexibility means you can "bookmark" ala social bookmarking in multiple contexts ... these bookmarks can carry meta data about a linked URI. That meta-data can be anything from contact notes to wiki entries. That could mean a new era of business applications that provide semantic inter-sections of web URI based on simple RESTful principles.
Imagine a BOM bookmarked and annotated in a del.icio.us type interface by different departments. A kitting department links the BOM to a history list that represents activities of kitting. Billing annotates accounting activity by bookmarking and logging the original BOM. The accounting system could be .NET, the kitting in PHP... it wouldn't matter. And you wouldn't need SOAP or known WSDL. The core system would be simpler and concerned with just web-page functions... and (using Grails) a scant few lines for context sensitivity to what the controller renders (XML, HTML, Ajax, JSON, etc.) ...meaning you can develop supporting systems each orthogonal to the data source system.
Think of it as meta-Aspect Oriented Programming if that makes you feel better about it. But, really, it's all about using REST and the web for what they are good at and leveraging the power of the browser as a broker platform. I've heard it called Browser As A Broker (BAAB) and also Enterprise Service Browser (ESB). I think I'll call it... simple and to the point.
Showing posts with label Software Design. Show all posts
Showing posts with label Software Design. Show all posts
2008-07-07
2007-12-27
New Year's Thoughts
According to Kurzweil your IT systems will be twice as powerful in 3 years. By 2013 or so we should be able to model a human brain in entirety on the world's most powerful machines. In time that power will hopefully trickle down to you and me. If you are like me, you write software, how are you going to use all that power? How are you going to produce all those features people need so rapidly?
If you've read my blog at all you'll know I'll tout the advance of the DSL and the dynamic language. I see these technologies on the JVM at a key inflection point between backwards compatibility and increased efficacy. They are transitional technologies at a key period in technological history.
The win in DSL, dynamic languages, and frameworks is always how succinctly you can get to your core thought or core idea. I don't really care about the ORM, the Ajax, the email most of the time. Most of the time there is a core idea I'm trying to work out.
In 24 months I need to be in the place where I can effectively divide the problems in front of me down into their key ideas. Keep the competing paradigms apart from each other. And then combine them at the right moments of confluence with a minimum of dissonance.
Get to the core thought, the core idea, ignore as much minutiae as possible, get the problem solved. Keep the idea clean. Keep the core thought from being tangled in a mess of details that have nothing to do with the answer you are after.
Advances in the way we create software will be key to the advance of the technologies of the future. If you are writing software today you will have to be prepared to leap a mighty chasm approaching us at break neck speed. That chasm will be paradoxically caused the increase of computational power available to us.
The problem of "traditional" programming that it is very procedural which can feel plodding at times. It takes forever to say anything meaningful. Yet before long we will have the ability to command computational power that could out strip our ability to speak into these systems with these sometimes unnecessarily verbose languages.
Consider that (in the video linked above) Kurzweil says that a scant 30 million bytes describes the whole of the human brain. The reason 30 million bytes could possibly hold the whole design for the human brain is that the brain's design is fractal and self organizing. A uniform underlying design is repeated with variation to create a whole. This is a similar goal to what we have in DRY (Don't Repeat Yourself) code that means we express an idea and leverage that idea again and again.
In the case of our brains, that assembled whole adapts to inputs to form intelligent variation leading to astounding complexity and abilities. The subtle variation introduced by input creates the mote of a soul... or at the very least all the personality traits we recognize as a living person. If only we could write software that could reorganize itself like that.
Functional programming, rules engines, and dynamic languages promise to free us from those mind-killing details that we don't really care about anymore as application developers. But they don't really address the need to create adaptive systems or systems that are able to span across computational mediums.
I predict that there will have to be new programming languages that run in new ways that allow for fractal designs like the human brain. I happen to think these still need to be languages because they are still conversations between a creator and the created system. I dream about these systems acting like holograms or fractals in their nature.
If you cut a hologram in half you get two identical but smaller and fuzzier holograms. If you look at one part of a fractal you see the whole. I think human designed software can have the same quality. The idea isn't new I've heard the opposite idea called "dirt" and perhaps that's a good word but in my mind these form knots ... asymmetric distributions of thought where one idea unrelated to another must intersect in incongruent ways. Perhaps "dirt" is the antithesis of "fractal" or "crystal" design.
I say "fractal" or "crystal" because "modular" isn't strong enough. You can make modules all day long but if they don't allow for cleanly intersecting concerns then you don't haven't done much more than take a messy room and shovel it's contents into random boxes. You haven't actually organized things you've just cut down on the size of the mess you have to sift through.
Good code focuses on one concern at a time and tries to ignore details that are incidental. It should be that in daily programming activities we can use tools like AOP and DSL to focus on the foremost thought ignoring details of execution. Good code is reusable because it encapsulates one concern in a way that is clean enough and simple enough to be easily lifted out and reused.
That's good stuff because if you're like me you really get paid for some high level thought and some high level idea and not the millions of tiny details you have to move through to get there.
If you've read my blog at all you'll know I'll tout the advance of the DSL and the dynamic language. I see these technologies on the JVM at a key inflection point between backwards compatibility and increased efficacy. They are transitional technologies at a key period in technological history.
The win in DSL, dynamic languages, and frameworks is always how succinctly you can get to your core thought or core idea. I don't really care about the ORM, the Ajax, the email most of the time. Most of the time there is a core idea I'm trying to work out.
In 24 months I need to be in the place where I can effectively divide the problems in front of me down into their key ideas. Keep the competing paradigms apart from each other. And then combine them at the right moments of confluence with a minimum of dissonance.
Get to the core thought, the core idea, ignore as much minutiae as possible, get the problem solved. Keep the idea clean. Keep the core thought from being tangled in a mess of details that have nothing to do with the answer you are after.
Advances in the way we create software will be key to the advance of the technologies of the future. If you are writing software today you will have to be prepared to leap a mighty chasm approaching us at break neck speed. That chasm will be paradoxically caused the increase of computational power available to us.
The problem of "traditional" programming that it is very procedural which can feel plodding at times. It takes forever to say anything meaningful. Yet before long we will have the ability to command computational power that could out strip our ability to speak into these systems with these sometimes unnecessarily verbose languages.
Consider that (in the video linked above) Kurzweil says that a scant 30 million bytes describes the whole of the human brain. The reason 30 million bytes could possibly hold the whole design for the human brain is that the brain's design is fractal and self organizing. A uniform underlying design is repeated with variation to create a whole. This is a similar goal to what we have in DRY (Don't Repeat Yourself) code that means we express an idea and leverage that idea again and again.
In the case of our brains, that assembled whole adapts to inputs to form intelligent variation leading to astounding complexity and abilities. The subtle variation introduced by input creates the mote of a soul... or at the very least all the personality traits we recognize as a living person. If only we could write software that could reorganize itself like that.
Functional programming, rules engines, and dynamic languages promise to free us from those mind-killing details that we don't really care about anymore as application developers. But they don't really address the need to create adaptive systems or systems that are able to span across computational mediums.
I predict that there will have to be new programming languages that run in new ways that allow for fractal designs like the human brain. I happen to think these still need to be languages because they are still conversations between a creator and the created system. I dream about these systems acting like holograms or fractals in their nature.
If you cut a hologram in half you get two identical but smaller and fuzzier holograms. If you look at one part of a fractal you see the whole. I think human designed software can have the same quality. The idea isn't new I've heard the opposite idea called "dirt" and perhaps that's a good word but in my mind these form knots ... asymmetric distributions of thought where one idea unrelated to another must intersect in incongruent ways. Perhaps "dirt" is the antithesis of "fractal" or "crystal" design.
I say "fractal" or "crystal" because "modular" isn't strong enough. You can make modules all day long but if they don't allow for cleanly intersecting concerns then you don't haven't done much more than take a messy room and shovel it's contents into random boxes. You haven't actually organized things you've just cut down on the size of the mess you have to sift through.
Good code focuses on one concern at a time and tries to ignore details that are incidental. It should be that in daily programming activities we can use tools like AOP and DSL to focus on the foremost thought ignoring details of execution. Good code is reusable because it encapsulates one concern in a way that is clean enough and simple enough to be easily lifted out and reused.
That's good stuff because if you're like me you really get paid for some high level thought and some high level idea and not the millions of tiny details you have to move through to get there.
2007-12-12
BPM is mostly wrong
In response to:
The Seven Fallacies of BPM
Mentioned in "The World is Flat" book Business Process Modeling systems were supposed to deliver businesses with a glorious future in which Business Analysts could model processes without the need for a programmer's intervention.
The problem is that the modeling process itself is core to application development and utterly central and important to a properly functioning application. You would no more have a Doctor design your house than you would a Business Analyst design a Database or Application. The Doctor is concerned with much different sets of concerns than an Architect is. The Doctor is concerned about wheel chair access and ventilation while the Architect is concerned with whether the building will stand up to a storm or earthquake.
While both a Doctor and Architect could collaborate to create a house you would not have a Doctor build a house unassisted. If you did you would be inviting disaster. And, you would be offended if I suggested that you take dietary advice from an Architect. That would be absurd.
It is true that many small projects are released without the help of a specialist. I'm certain many buildings are built without an Architect... and many diseases are overcome without a Doctor. But, you should ask yourself what your project is? Are you trying to produce a professional product or are you just "hacking around" looking to make something that works? Do you want to create "professional" systems or just "hobby" systems. Are you producing a reliable car or are you creating a dune buggy in your back yard?
If you can honestly answer that the project you are producing is a "buggy" then by all means forgo the professional assistance ... but don't kid yourself... that's not a Toyota you've got.
The Seven Fallacies of BPM
Mentioned in "The World is Flat" book Business Process Modeling systems were supposed to deliver businesses with a glorious future in which Business Analysts could model processes without the need for a programmer's intervention.
The problem is that the modeling process itself is core to application development and utterly central and important to a properly functioning application. You would no more have a Doctor design your house than you would a Business Analyst design a Database or Application. The Doctor is concerned with much different sets of concerns than an Architect is. The Doctor is concerned about wheel chair access and ventilation while the Architect is concerned with whether the building will stand up to a storm or earthquake.
While both a Doctor and Architect could collaborate to create a house you would not have a Doctor build a house unassisted. If you did you would be inviting disaster. And, you would be offended if I suggested that you take dietary advice from an Architect. That would be absurd.
It is true that many small projects are released without the help of a specialist. I'm certain many buildings are built without an Architect... and many diseases are overcome without a Doctor. But, you should ask yourself what your project is? Are you trying to produce a professional product or are you just "hacking around" looking to make something that works? Do you want to create "professional" systems or just "hobby" systems. Are you producing a reliable car or are you creating a dune buggy in your back yard?
If you can honestly answer that the project you are producing is a "buggy" then by all means forgo the professional assistance ... but don't kid yourself... that's not a Toyota you've got.
2007-10-12
The new Alfresco
TriLUG last night had a special presentation from principal architect Jon Cox. Jon Cox had developed software for the Interwoven product suites and is now working for Alfresco which has released a new versioning engine based on Jon's work.
The new alfresco tool's new features include Native Office integration, multiple locking models, adaptive workflow engines based on jBPM, REST style API, a new Web 2.0 front end, web portal integration, and web content management features. The big win here is the long awaited Office integration. Unfortunately, this feature is apparently very new and doesn't have good documentation around it yet.
For a programmer the most common use of versioning is in source code version management with tools such as SVN. The difference between Alfresco and SVN was described by Cox using this analogy:
Imagine you have a window pane and you are looking at the Mona Lisa. You can draw on this pane, erase it, do what ever you want and no one but you can see it. Now imagine there are three of you... Alice, Bob, and Charlie. Charlie puts a mole on Mona Lisa, Bob puts a mustache, and Alice adds a goatee. If Charlie commits (permanently saves) his mole Alice and Bob will suddenly see the mole show up underneath their window panes.
This is very different from source code control in products like SVN and CVS. In source code the developers all have their copies that they work on. When they are done they commit their changes. In SVN if Charlie has committed that mole neither Alice nor Bob will see the mole until they go to commit. When they try to commit they get an error. Alice and Bob each have to update manually and then make changes to accommodate Charlie's mole addition.
This is inappropriate behavior for managing documents. And, that is why Alfresco can be set up with either pessimistic locking (source code type locking) or optimistic locking (everyone sees each other's changes immediately).
I took away these key concepts:
Alfresco versioning composed of three layers... The official copy, the working copy, and the preview.
The official copy is like the Mona Lisa under glass, the working copy you have is like a pane of glass that you can draw on and no one can see. The preview exists behind you as a preview that you can send "links" to other people who can then look "over your shoulder". This set of concepts allows people to play "what if" scenarios with their documents and web sites.
The working copy can pass through an approval process before it reaches the official copy. You may snapshot a working copy before you send a preview and only allow a preview of the snap shot. And all this can be used to version sets of documents or websites.
Toward the end of the talk Jon entertained the long term vision that the Alfresco object-version system could be used for source code control. It would allow for the implementation of different policies on how source code could be modified and worked with... and could be used to implement radically different software work patterns then what we use now.
The new alfresco tool's new features include Native Office integration, multiple locking models, adaptive workflow engines based on jBPM, REST style API, a new Web 2.0 front end, web portal integration, and web content management features. The big win here is the long awaited Office integration. Unfortunately, this feature is apparently very new and doesn't have good documentation around it yet.
For a programmer the most common use of versioning is in source code version management with tools such as SVN. The difference between Alfresco and SVN was described by Cox using this analogy:
Imagine you have a window pane and you are looking at the Mona Lisa. You can draw on this pane, erase it, do what ever you want and no one but you can see it. Now imagine there are three of you... Alice, Bob, and Charlie. Charlie puts a mole on Mona Lisa, Bob puts a mustache, and Alice adds a goatee. If Charlie commits (permanently saves) his mole Alice and Bob will suddenly see the mole show up underneath their window panes.
This is very different from source code control in products like SVN and CVS. In source code the developers all have their copies that they work on. When they are done they commit their changes. In SVN if Charlie has committed that mole neither Alice nor Bob will see the mole until they go to commit. When they try to commit they get an error. Alice and Bob each have to update manually and then make changes to accommodate Charlie's mole addition.
This is inappropriate behavior for managing documents. And, that is why Alfresco can be set up with either pessimistic locking (source code type locking) or optimistic locking (everyone sees each other's changes immediately).
I took away these key concepts:
Alfresco versioning composed of three layers... The official copy, the working copy, and the preview.
The official copy is like the Mona Lisa under glass, the working copy you have is like a pane of glass that you can draw on and no one can see. The preview exists behind you as a preview that you can send "links" to other people who can then look "over your shoulder". This set of concepts allows people to play "what if" scenarios with their documents and web sites.
The working copy can pass through an approval process before it reaches the official copy. You may snapshot a working copy before you send a preview and only allow a preview of the snap shot. And all this can be used to version sets of documents or websites.
Toward the end of the talk Jon entertained the long term vision that the Alfresco object-version system could be used for source code control. It would allow for the implementation of different policies on how source code could be modified and worked with... and could be used to implement radically different software work patterns then what we use now.
2007-08-30
Where do we go now?
Last year Google dropped their SOAP API and today they announced that You Tube launched a new API. That got me thinking.
This Google-hate-on-SOAP was covered at my NFJS conference, the reason cited was the strong typing issue in SOAP.
As I've written SOAP services I've found that you get tied to the POJO or DTO object that you write. This is okay if you are a small shop and you control both end points (read "me") but it becomes a problem when you have 3rd parties working with your services. The problem gets pretty bad after a half dozen versions...
What to do? Well, apparently if you ar a multi-billion dollar organisation you do this:
Google Data API
Which is the google answer to the problems in SOAP. Now if you aren't Google you could do a few different things... you could just use the GData libraries... reverse engineering your own back end for them since they don't release the server side code for this stuff... or you could do what was suggested by the ThoughtWorks consultant at NFJS... you _could_ do loosely typed SOAP services.
Huh?
A loosely typed soap service is a soap service that takes an XML document as its only parameter. That means your method names change from
to
which doesn't seem all that profound from the method signature but it does introduce a bit of pain. The pain introduced is in the necessity of implementing a strategy pattern...
Strategy Pattern
... in this case you would have a collection of parser or processing engines that would return a result document. The particulars on which result and how we get it are determined by the concrete implementation.
But even this seems a little hackish. But, take a look at this:
stone mind on rest, groovy, and other things
And, I think this sums up where my mind is headed. After spending a lot of time hacking around in the J2EE playing grounds where there are all kinds of horribly stodgy things, conflicting ideas, and just plain crazy ideas... I've come away with a couple of golden nuggets I'll share with you and where I think the technology stack will be in three years.
I don't have an affinity for Python. I don't have a particular love of plain old Java either, but I do have a yen for many tools that Java lovers have. I love their XML handling tools. I love entity manager based persistence engines.
I think Groovy is going to be a major player for shops like mine where we have a need to work with Java and other tool chains too. We need to get things done quickly but we also need to be a bit stodgy at times. Groovy means we can bring in the Java "enterprise" stack without choking on the "enterprise" part.
Grails helps a lot too. It is rapid application development, MVC, Hibernate3, and Spring in a box and you can crank out applications in it once you know what you're doing. The trouble is getting to know what you are doing if you are a PHP programmer. (which we can find... but not JSP programmers)
I think there needs to be a few more Grails books. But I'm adept at figuring things out and I can get by without a book. I'm impressed that Grails has a DWR plugin so that means the best of all possible worlds.
I am looking forward to getting things done with Java, Groovy and Grails in the next couple of months. I think Groovy will take off in the next few years and legitimize the dynamic language on the Java stack. Groovy is just variant enough off of Java to improve development cycle but close enough to Java to keep the barrier to entry low.
This Google-hate-on-SOAP was covered at my NFJS conference, the reason cited was the strong typing issue in SOAP.
As I've written SOAP services I've found that you get tied to the POJO or DTO object that you write. This is okay if you are a small shop and you control both end points (read "me") but it becomes a problem when you have 3rd parties working with your services. The problem gets pretty bad after a half dozen versions...
What to do? Well, apparently if you ar a multi-billion dollar organisation you do this:
Google Data API
Which is the google answer to the problems in SOAP. Now if you aren't Google you could do a few different things... you could just use the GData libraries... reverse engineering your own back end for them since they don't release the server side code for this stuff... or you could do what was suggested by the ThoughtWorks consultant at NFJS... you _could_ do loosely typed SOAP services.
Huh?
A loosely typed soap service is a soap service that takes an XML document as its only parameter. That means your method names change from
@WebMethod
public User getUserByComplex(ComplexObject complex)
to
@WebMethod
public XmlDocument getUser(XmlDocument xml)
which doesn't seem all that profound from the method signature but it does introduce a bit of pain. The pain introduced is in the necessity of implementing a strategy pattern...
Strategy Pattern
... in this case you would have a collection of parser or processing engines that would return a result document. The particulars on which result and how we get it are determined by the concrete implementation.
But even this seems a little hackish. But, take a look at this:
stone mind on rest, groovy, and other things
And, I think this sums up where my mind is headed. After spending a lot of time hacking around in the J2EE playing grounds where there are all kinds of horribly stodgy things, conflicting ideas, and just plain crazy ideas... I've come away with a couple of golden nuggets I'll share with you and where I think the technology stack will be in three years.
I don't have an affinity for Python. I don't have a particular love of plain old Java either, but I do have a yen for many tools that Java lovers have. I love their XML handling tools. I love entity manager based persistence engines.
I think Groovy is going to be a major player for shops like mine where we have a need to work with Java and other tool chains too. We need to get things done quickly but we also need to be a bit stodgy at times. Groovy means we can bring in the Java "enterprise" stack without choking on the "enterprise" part.
Grails helps a lot too. It is rapid application development, MVC, Hibernate3, and Spring in a box and you can crank out applications in it once you know what you're doing. The trouble is getting to know what you are doing if you are a PHP programmer. (which we can find... but not JSP programmers)
I think there needs to be a few more Grails books. But I'm adept at figuring things out and I can get by without a book. I'm impressed that Grails has a DWR plugin so that means the best of all possible worlds.
I am looking forward to getting things done with Java, Groovy and Grails in the next couple of months. I think Groovy will take off in the next few years and legitimize the dynamic language on the Java stack. Groovy is just variant enough off of Java to improve development cycle but close enough to Java to keep the barrier to entry low.
2007-07-20
Document Centric Design?
The Idea is that documents represent a single common data format for all processes. All processes produce or consume documents. A process that consumes no documents is called an originating process. A process that only consumes documents is called a terminating process.
Key Concepts:
In addition consider that all updates should themselves be a new process and document.
Key Concepts:
- Business Processes shall produce documents
- documents can never be changed
- documents record answers & decisions
- not necessarily real documents (like *.xml, *.pdf, *.doc) but perhaps table structure
- Business Processes consume documents
- documents from other processes may feed this process
- processes may develop natural dependencies based on the documents they need
- processes may raise alerts based on the documents they need
- some processes may not require any documents, these are originating processes
- Originating Processes begin a new workflow
- they originate a new workflow
- they have no prerequisite documents
- Business Processes are versioned and concurrent
- clients default to starting the newest defined process under a given name
- documents in process will finish in the version they started in (this is not to say you couldn't terminate processes to force people to use a new version )
- Interviews are Processes concerned with asking questions
- Interviewees are the people taking an interview
- An Interviewer is a person filling in an interview form for a person
- A Self-Directed Interview is an online interview with no human interviewer (the computer is conducting the interview)
- answers are unique to an interviewee
- answers relate to facts that we can assert about an interviewee.
In addition consider that all updates should themselves be a new process and document.
2007-05-29
A year with Java 5 EE
I've spent the last year with Java 5 Enterprise Edition betas and I'm going to talk about my experiences with the Java environment as a relative newcomer to the Java landscape. My background is in C/C++ System V programming on Linux, Solaris, and Irix systems. It has been a hard year but one that I'm thankful for. I've learned a lot about how Service Oriented Architectures go together, why they work, and why they fail.
2007-02-12
Software Metaphor: Chop Sticks versus Formal Cutlery
Consider the simplicity of chopsticks versus the complexity and elegance of formal cutlery as demanded by a formal table setting.
In the past cutlery was far more complex yielding exceptionally specialized tools for every dining situation. The complexity of formal dining utensils is just plain daunting to the neophyte. A different fork for every function. A different spoon for every food. A knife for butter, a knife for bread, a knife for fish and on goes the list.
Now, consider the chopsticks. Every food imaginable can be eaten with the chopsticks. Need to cut? Scissor your chopsticks to slice. Need to stab your food to get a hold of it? Stab the item of food with a single stick. Need to scoop food? Form a wedge with your sticks and scoop away. There is no need to learn a proliferation of tools, just one tool. Use this one tool well and all of life's dining problems are solved. Or, just avoid the problem entirely and lift the soup bowl to your mouth... have the chef slice the food smaller... if all else fails... don't eat that.
In Software Engineering we face the battle between chop sticks and cutlery every time we start a new project. Should I use a specialized technology? Should I use the chop sticks I know so well? The happiest Software Engineers learn to use chop sticks, and when problems get sufficiently messy, the learn to put down the sticks and pick up the right utensil. They keep the utensils down to knife, fork, and spoon if possible to avoid the over-head of having too many tools.
Don't fall into the "hammer" problem where in you see every thing as a nail needing to be hammered, yet keep away from the Victorian table setting if at all possible.
In the past cutlery was far more complex yielding exceptionally specialized tools for every dining situation. The complexity of formal dining utensils is just plain daunting to the neophyte. A different fork for every function. A different spoon for every food. A knife for butter, a knife for bread, a knife for fish and on goes the list.
Now, consider the chopsticks. Every food imaginable can be eaten with the chopsticks. Need to cut? Scissor your chopsticks to slice. Need to stab your food to get a hold of it? Stab the item of food with a single stick. Need to scoop food? Form a wedge with your sticks and scoop away. There is no need to learn a proliferation of tools, just one tool. Use this one tool well and all of life's dining problems are solved. Or, just avoid the problem entirely and lift the soup bowl to your mouth... have the chef slice the food smaller... if all else fails... don't eat that.
In Software Engineering we face the battle between chop sticks and cutlery every time we start a new project. Should I use a specialized technology? Should I use the chop sticks I know so well? The happiest Software Engineers learn to use chop sticks, and when problems get sufficiently messy, the learn to put down the sticks and pick up the right utensil. They keep the utensils down to knife, fork, and spoon if possible to avoid the over-head of having too many tools.
Don't fall into the "hammer" problem where in you see every thing as a nail needing to be hammered, yet keep away from the Victorian table setting if at all possible.
Subscribe to:
Posts (Atom)