Mar 11 2010

10 reasons to use or not use Scrum

Category: Development Tools | MethodologyJonathan @ 02:39

When to utilize SCRUM:
  • When requirements are sketchy and poorly gathered
  • When there are new requirements
  • When existing functionality needs to change
  • When you are fire-fighting bugs, issues and points of failure
  • When you need to quickly get back into good grace with the client after tons of issues
  • During the very initial investigations of the project, research and understanding user stories
  • When Use Cases are not being met properly and you need to get things on track functionally
  • When new members join a team, or an increase in communication is required.
  • When the product owner needs to balance a backlog
  • When there is a lack of responsibility and accountability
When NOT to utilize SCRUM (prefer a more Agile Methodology)
  • Gathering requirements
  • Designing the system functionally
  • Designing the system architecturally
  • Core Development phases
  • Development phases which require design
  • Phases dedicated to Refactoring
  • Phases dedicated to Testing
  • When roles and responsibilities are defined properly
  • When requirements are consistent and relatively static
  • When management and interested parties are not committed to it

SCRUM is not a silver bullet and no team, in my opinion can afford to put all their eggs or life-cycle phases into one basket.

Updated:
Scrum or being agile is not something that can solve your problems. It is rather the the team, leadership and real productive processes that count more than anything. A person unskilled in leadership and who does not have the complete 'vision' will fail in whatever processes are in place. And those that are good at leadership and management, were agile and good at it, before any methodology was created.

I think most importantly, a leader must care, be focused, be open minded and must seem to 'see into the future', as his intuition will show through.

Tags: , ,

Mar 4 2010

The Gap between Agile Methods and Agile Development

Category: Development Tools | MethodologyJonathan @ 03:33



Agile Methods are a people-centric way of running projects where increasingly teams are accepting that it has tremendous value. However there is more weight put on the code for an Agile Method based project, as with more deployments, milestones and iterations, there is either a need for more refactoring over time, or a more future-proof design is needed. However both refactoring tools and greater predictive powers on the future of the code are both valuable tools.

However, if the software being crafted is not of an equally high and maintainable standard, the project can also fail at being more agile, (just like a people-centric approach can fail with the wrong set of people, irrelevant or bad design can affect the iterations and deadlines).

The software design should also be crafted in an Agile way, to support the Agile Method governing the people. However, being more agile in code does bring in some side affects.

  • An increase in software abstraction
  • An increase in configuration and meta data
  • An increased requirement for intelligent design
  • A more controlled, standardized, patterned and convention based development environment


Currently though, I see a gap between the Agile Method and the code written within the project. ie. the relationship between the agile software and the Agile Method.

There are many reasons why teams using Agile Methods could fail and I include design and coding into that list.

I believe that:

If being more agile is being more 'adaptive' (rather than predictive), then being more agile in code, needs the counter-weight, which is 'predictive', rather than 'adaptive'. I believe code should be more predictive of future changes, the more adaptive the business becomes. The balance of the two concerns is where you will find a good software system with happy clients. It is all the balance.

Tags: , ,

Jan 20 2010

Interface Phasing

&


On the concept of contracts and contracts, I think we need "interface phasing". Having a phased relationship between two parties.
It is imperative that objects and at a higher level, an Application, can change the way they interact by who or what is accessing them.

 

An object should present itself differently to different audiences. Imagine a developer seeing a specific interface, but not a user, or IDE vs developer. Its not role based, because it could be different per application to application communication, although a similar effect can be achieved.

The concept is simple.

I think that coding today suffers from

  • Repetitive nature of structural elements: for example: creation of large Object Models, classes, properties, collections and so on.

  • Creating Object models with no separation of Context or concerns. I want an object to 'share' code, but for different reasons. Cross-Cutting. Yes, I can create a new object and share code, but that's not always the answer. Imagine two object models, where one is a Facade of the first. I want to simply map the one to the other, not create the entire structure for it again.

  • Different ways of extending components. Different ways of creating add-ins, Custom B2B, Adaptors, Bridge patterns etc. It can all be made easier, if we used a "Global extension object system"

  • The 'under the hood' 'abstractions, keep changing - not for the better or necessarily for the worse, but for no distinct benefit.

  • Contractinitis - Nothing works unless its all explicit. In .NET, can't call the web service with your Person Object, cause its not the same namespace etc.

 

Create automatic and dynamic proxy layers based on metadata and intention of communication. The code is then 'assembled' and made ready for the communication. The code is assembled from existing non contextual code that can fit into a common proxy container and interact.

On a simple level, imagine, you create SOA like methods, stateless and they are formulated by the runtime into a new object that looks like the one required.

This is not the complete answer, but we really need to get to 'smarter relationships' rather than contracts.

See Lack of MetaData on code and .NET Framework libraries

Read Evolution, Architecture, and Metamorphosis - A great piece of work.

 

Tags:

Jan 20 2010

The Concept of Non Contractual interfaces


Our software contract world is the accepted norm, and of course we have come a long way with the philosophy as its been the corner stone of our development languages and platforms for how long.
However, other concepts have also existed. In the seemingly archaic world of top down programming, there were no interface or object-oriented contracts. Instead a form of duck-typing and vtable calls ruled the day or even worse pointers and addresses.
Today the concepts of interface and implementation etc are sometimes lost on the new generation of developers, as its so seamless today.
However, I think that if you look at the real world, communication is lossy, and not defined by the same kind of rules.

In the real world we kind of just make sure there is someone around, or get the person focused on us, then we talk. The receiver understands or does not understand, or does not listen, or hears and acts on all that is said. In the real world, not every communication has "roger", "over and out". There are obvious benefits to having it sometimes, but a real pain in other situations.

The interaction of software frameworks is a real candidate for a more lossy communication, or a Communication Agent, put in software terms. The ability to translate messages from "intention to result" is imperative.

When a call is made to string GetUserName() or string getNameOfUser, the intention is the same, but in our current forms of software architecture, a human would have to use a design pattern, Adaptor, Bridge or whichever suited to accomplish it, when clearly, to our human eyes, the function could well be identical but for name.

A new kind of Interface Definition language is needed to declare intentions of interfaces, and allow a mapping agent to successfully arbitrate a result.

Tags:

Jul 23 2009

ASP.NET Framework Should Haves

Category: .NET | asp.net | c# | Design | Development Tools | Visual StudioJonathan @ 05:53


ASP.NET should have been a plug-in from the start. The IIS Handler, should have been split into (.NET with ASP.NET) and (.NET without ASP.NET). The idea of a config file and a WebConfigurationManager is not and should not have been specific to ASP.NET.

One cannot help but feel that ASP.NET was designed with Web Server Controls as the flagship feature. "Create that 3rd party market for web". No real thought paid into how people actually use the web on simple terms.

What I am writing here, probably resembled the paper David Heinemeier Hansson scribbled on when thinking and designing Ruby on Rails, but I have no intention of mapping features, just stating the obvious.

Get Server returns html
Post Server *saves data and returns html
Querystring may change what code is executed, and change the "context"
Url may require changing, remapping, extension changes etc

Now, to do this in ASP.NET is relatively straight forward?
Yes it is, simple enough to do each thing, but it gets more complicated when you want all these ideas together.

There is also a grey area as to what we should call easy. Yes it's easy to do x, but is it simple and will it remain simple as time goes by.
The minute you start asking some questions, ASP.NET starts to give varying levels of success. What if it was posted from a different server? What if the html had to be static and not dynamic? what if you need to create your own physical files and return those to the browser? What if you did not want an aspx page at all? What if your new Module wants to create the Page (HttpHandler)

Asp.NET is far too cluttered, and muddled. The design from, Web Server to a response, should have been completely extensible and pluggable.

The problems that I have come across, over the last few months (again), have all been relating to ASP.NET not being able to let go. ASP.NET has so many tenuous links to what you write, its everything but impossible to break away.

A framework should always be designed in layers. A framework should not be a large foundational block, written to sit at the bottom only.

if I am not entirely clear, perhaps a few links into oddities will help.
Actionless Form
Scenarios where switching viewstate off like this does not actually work.
and why caching problems like this does not work properly all the time.
Double postback scenarios
The ridiculous IsPostBack code and scenarios
and it does not end. Friendly adaptors, bad html to asp.net naming, lack of rudimentary support for url manipulation, deflected posts and more, makes ASP.NET a framework look like this.

In my humble opinion, on design/framework notions here are some ASP.NET should haves.

  • The HttpRuntime and associated server objects should have been better formulated and allow for better involvement. Allow extensibility.
  • The runtime should have made Pages (HttpHandler) an optional unit of packaging and code, not the complete target.
  • Better fine grained Page type. Split it into more pieces, separating cache, viewstate and more from the design. So we can use at any of the levels of interest.
  • HttpHandlers should have been designed as a clear open and extensible list of handlers. The pattern should be more workflow like.
  • The compilation process of asp.net syntax and html should have been an exposed set of objects, also extensible. (build providers)
  • Expressions should have been designed much better, and give us control of more of the syntax.
  • It should have been easy to create an aspx file and not have code behind, and include your own syntactical sugar.
  • Asp.NET should have been a plug-in to the .net engine for the web, and not soo tightly coupled.
  • Classic ASP should have been a continued 'available' and compatible unit within the framework.
  • Should have reduced the gap between Server and Client side code. not server controls writing client code out, but rather a whole new better solution
  • ClientID $ in Form and _ in Page? why not allow us to switch it off?
  • All that time it took to develop usercontrols and pages and server controls, could have been better spent on using existing syntax and an html object model for controls. It would have been compliant, less error prone and significantly better.



Personally, I cannot wait for the rewrite of ASP.NET. Unfortunately with all the man hours, money and face they have put into ASP.NET - they wont be brave to throw it away. Yes folks you will be stuck with it, and its even going to version 4.

I like the .NET framework as a whole, I love the c# language, but ASP.NET is a beast. Why on earth they built MVC on top, I'll never know. If it was not for Visual Studio supporting ASP.NET, it would be a disaster.

ASP.NET just should not have!

Tags: , ,

May 22 2009

Lack of MetaData on code and .NET Framework libraries


Although .NET Reflecton offers a decent look at the Types you build, it is pretty generic in its offering. For example, it does not yet provide us with capabilities to control and secure how Reflection can inspect our Types. If you do not want a Type to be Instantiated via Reflection, or if you would like to restrict certain Types from being visible at all. Further there is no idea for extension or change. One cannot simply plug into Reflection and override behaviour.

High abstractions and higher flexibility

Many more wrappers are needed, at a higher level, which would sit on top of .NET Reflection. For example, architectural dependencies. Agile mechanisms, if code had enough metadata attached, one could alter the code via reflection/refactoring in a much more dynamic way. Consider the following two web service methods in two different companies.
  public class PersonService
    {
        public void AddPerson(string lastname, string firstname, 
            string birthdate)
        {
        }
    }

    public class PersonWebService
    {
        public void AddNew(string firstname, string surname)
        {
        }
    }

You can see that they are completely different contracts. Interface and contract speaking they are like apples and sand. However, to your mapping, calculating, schema, metadata, tagging and understanding brain, its the same thing.

What we need, is to remove ourselves from Contracts to something more like guidelines.

  public class PersonService
    {
        [Operation(Schema:Person, "Add")]
        public void AddPerson([schema(LastName)]string lastname, 
             [schema(FirstName)]string firstname, 
             [schema(DateOfBirth)] string birthdate)
        {
        }
    }

    public class PersonWebService
    {
        [Operation(Schema:Person, "Add")]
        public void AddNew([schema(FirstName)]string firstname, 
             [schema(LastName)]string surname)
        {
        }
    }

Tags: , , ,

May 13 2009

VS.NET Add-ins worth looking at

Category: .NET | Development Tools | DOTNET | Visual StudioJonathan @ 04:53

Run VS.NET as Administrator on Vista.

Export your settings using Tools | Import and Export Settings, don't let another windows reinstall take it all away from you.

Get Regionerate
- but make sure you use the "Remove All regions" command, before trying to apply others. It wont replace your existing regions.

Get Studio Tools, for File manager and the tear off editor.

Download Dev /efor - not sure about the name, but it works nicely.

Snippet Editor, useful, for changing the way the existing snippets work, as well as new ones.

Carl J has a large list of add-ins.

Tags:

Mar 2 2009

All New DSL's will be 2nd Class Citizens until at least 2018

Category: .NET | Design | Development Tools | Visual StudioJonathan @ 03:29

So you have heard of Domain Specific Languages, maybe even wrote your own. Maybe even rolled it out to the public. Maybe you don't believe you have used a DSL? What about Cascading Style Sheets? Ever used CSS?

Very soon we have to answer a very important set of questions.
How do we use the language? Text Editor? Smarter tools such as Eclipse or Visual Studio? How does it integrate with other languages?

The Common Language Runtime (CLR) puts Microsoft at the front of all this? or does Eclipse have what it takes to adapt?

More...

Tags: ,

Jan 30 2009

My Interview with Kent Beck

Category: Development Tools | MethodologyJonathan @ 02:26

Hi there DevFans>

Next week, is going to be "just brilliant". I am going to have, none other than Mr Kent Beck, chatting to me about Extreme Programming (XP) and other software issues, right here on my website.

He is a pioneer and real credit to our industry, and I am delighted to have the opportunity to speak with him on your behalf.

The interview will be recorded, and then put up on my feed and of course in iTunes. If all goes well, it will be available on the Friday. So get subscribed, ready for action.
To subscribe, click on the PodCast icon on the top right of my website, or just search in iTunes for my name.

Now which brings me to...

Call to Action

Along with my questions, I would just love to pose some of your questions as well. So if you have anything you want answered, if you have anything you wanted to know from the man himself, now is your chance. Send me your questions, and I will choose the best ones for inclusion.


 

Kent Beck


Kent Beck 
Kent Beck is the founder and director of Three Rivers Institute (TRI).
His career has combined the practice of software development with reflection, innovation, and communication. His contributions to software development include patterns for software, the rediscovery of test-first programming, the xUnit family of developer testing tools, and Extreme Programming. He currently divides his time between writing, programming, and coaching.

Beck is the author/co-author of Implementation Patterns, Extreme Programming Explained: Embrace Change 2nd Edition, Contributing to Eclipse, Test-Driven Development: By Example, Planning Extreme Programming, The Smalltalk Best Practice Patterns, and the JUnit Pocket Guide. He received his B.S. and M.S. in Computer Science from the University of Oregon.
Three Rivers Institute 

Kent is currently researching effective software design. If your company is interested in sponsoring this research in return for early access to his results, please contact him directly. His other business activities include contract programming using Java/Eclipse, writing, consulting (mostly remote), and presenting workshops with his partner Cynthia Andres.

 


Tags: , , , , ,

Jan 26 2009

An Even better Idea: Abstract the Code file from the Language

and the editor provides you with visualizations of the code file, which contains a base language, metadata and more contextual information.

The Web 2.0 of Code Editing?

Currently, and even our new tools, like OSLO, when its released, is and will be file based.
Now that in itself is fine, to keep in line with source control and other file based tools. But our Integrated Development Environments require a better, a whole new kind of Code Editor.

I believe that we need to create what I tentatively call ActiveEditors. An ActiveEditor is one which as described above surround code snippets, understands a lot more about Context and the code we write. In order to do that, it should build a Code Tree, Abstract Syntax tree -LIKE, Object Model, separating the FILE from the Editor.

This means that we open a FILE, but view an ActiveEditor, showing a generated “view” of the file.

The actual file and the contents could be XML, or MSIL, but what we see (via built in CodeGen), is c# or vb. So the actual code file needs not be in a particular language.

What does this do? It provides an abstraction that creates a dynamic representation of the code file, in your language. Have a look at the picture. The file could store c#, but it never directly puts the textual content of that file in the editor. Instead, it generates the code, from the model, built from the file, and pushes that into your editor. Based on a setting, the file could be MSIL, and your view could be C#, or any combination.



Now you could write an entire project in c#, but at anytime, switch to VB.NET, and it would never affect anything, because the compiler is compiling the actual file, not your Visual Display within your ActiveEditor that was created.

How would it help?

We could potentially store MetaData within the Code Tree, that would be excluded from viewing, although kept in the file. Your language choice and the code could still be generated as you are used to it. (think code-behind, where the sub document is the base language, which you can show/hide).
This new MetaData, would then actively describe the code so that Code Generation tools and the Editor can manipulate it for context, refactoring and other.


The next big thing? Coming to Visual Studio 10? is it too late ?

Imagine your Visual View of the code had toggle switches, to show/hide comments, show/hide regions, show/hide methods, show/hide classes - it would still be in the actual file, but not in your Visual Display. In the same way, I could switch my Visual Display to VB.NET to edit something, and then switch it to c# to edit something else.
Each developer on the team can view and edit in the language of their choice, it would not matter.
If a team of two was using vb.net, and then 3 more developer were brought on the team, they could continue in the same project in their own language, and it would not change anything.

Tags: , ,

Jan 25 2009

Code Generation Tools

Category: c# | CodeGenWeek | Design | Development Tools | DOTNETJonathan @ 18:11

All your code are belong to us

Send me a list of your favorites and I will compile a list of them on the website. For now, here are some ad-hoc random ones to perhaps try out. if you know anything about any of these, let me know what you think of them.

http://www.codesmithtools.com/
http://www.ibm.com/developerworks/rational/library/2949.html http://www.tangiblearchitect.net/visual-studio/
http://www.raboof.com/Projects/VsCodeGeneratorShim/
http://www.microsoft.com/downloads/details.aspx?familyid=89e6b1e5-f66c-4a4d-933b-46222bb01eb0&displaylang=en
http://www.jetbrains.com/resharper/
http://www.oracle.com/technology/tech/dotnet/tools/index.html
http://www.mygenerationsoftware.com/portal/default.aspx
http://www.codeplex.com/jeremydotnet
http://www.altova.com/solutions/code-generation-tools.html
http://www.devexpress.com/Products/Visual_Studio_Add-in/Coding_Assistance/
http://www.eurowisesoft.com/
http://www.dotnetsavant.com/
http://www.adonetexpress.com/
http://www.bluage.com/
http://www.razorsource.com/SourceCutter/Overview.aspx
http://www.developerinabox.com/
http://www.innoq.com/iqgen/index.html
http://www.sd.nl/software/
http://www.radsoftware.com.au/codegenerator/

Steve Hansen sent me a link to m-Power

Tags:

Jan 24 2009

One important reason why your Code Generation tool does not get used

Category: .NET | c# | CodeGenWeek | Design | Development Tools | DOTNET | TalkWareJonathan @ 04:20

You say “m_” , I say “_”, lets call the whole thing off!

Code Generation has one tremendous problem.
We dont like the way the code looks.
Majority of the code spat out, is, if not badly formatted, then not formatted the way I like.


Hi, after you read this post, don't miss my Interview with Kent Beck coming soon.


and it does not change the formatting when you don't like the way it was generated or you have to fiddle with codegen settings (which for every tool is different). There are other reasons of course why codegen is not 100% accepted, like you cannot edit the generated code. If you do, it mostly quickly gets overwritten by the next run of the codegen.
But this is already being addressed (a little) by partial classes in .NET, BUT there is still no answer for the formatting problem.

AND let's face it, if any helpful and usable code was generated and it looked like our own code, we would be more inclined to use it.

Introducing JIT Code Formatting

it is not altering the actual layout of the file, it's just the "view" of it.
Just in time code formatting is the process of changing the formatting of any code, no matter how it looks on disk, "to the way you want it". Imagine I send you a small project, you open it and find I have prefixed all fields with an underscore. Your development tool, understanding the semantics and changes the variable prefixes for you when you open it. It formats out the code the way you like it and likewise, when I open it, its changes it the way I like it. It is not altering the actual layout of the file, it's just the "view" of it.

Checking the source into Source Control is not a problem, as it would convert it to a consistent format for before checking in.

For example: In Visual Studio, you would have settings for how you want your formatting. The formatting can be set and pushed to all developers and each developer can have the formatting the way they need and like it.

The JIT-CodeGen engine translates the code to your settings.

Now who wants to write this?

SideBar

Built-in CodeGen in Visual Studio

The T4 templates are an example of a powerful feature in Visual Studio, incorporating code generation, however it will generate the code based on the developers ideas, conventions and standards. This is one of the problems of codegen adoption.
However T4 from Visual Studio is still very cool. Read a little intro by Rob and from Scott

There are many new features coming in Visual Studio 2010, but where is this feature? There is still time, to add it in.

Listen Now:




Download

CodeGenWeekPodCast1.mp3 (7.55 mb)


iTunes

Copy this address: http://www.jonathancrossland.com/syndication.axd and paste it into iTunes.



Tags: , , , , , ,