Chris Donnan : Programming – Brooklyn Style

23/05/2007

More on plinko style architecture – how do we do architecture?

In a prior post I talked about how important it is to “slice the work vertically” and not to get lost in BDUF land. In general, I think architecture needs to be “right sized” to the project. A teeny app needs little or no real “architecture planning” a huge app certainly needs some. The trick is not to think you can do BDUF for real, you just hide work and make the other BDUF believers “feel comfortable”.

I am certain in my current role that people think I am “a classic agilist” ready to run off and work with no longer term vision, plan, agenda. If we do that, we will surely get into a bad place is the criticism.

  • I believe that NOT writing tests
  • Not acknowledging technical debt and addressing it
  • Not time boxing
  • Delivering infrequently to the cleints
  • Inexperienced developers/ naieve assumptions

These are the primary things that make you “get in a bad place in the future”. Certainly – refactoring on the enterprise scale costs lots of $ as you are forced to change lots of nodes/ components/ layers. Limiting the scope of refactoring is very important at the enterprise level.

Blah, blah, blah – so what is this architecture business and how do we do it? I have been using this simple model:

The plinko architecture formula

  • Prior art (someone did something like this in the past)
  • Vision (if we had this XXX, then all these other problems would go away)
  • Collective experience of the team
  • Well known components (we KNOW we will be using our corporate XXX service/ component/ etc)
  • +
  • Development Spike (time box, rapid prototype 10 ways to solve each problem)
  • =
  • “Ballpark architecture”

This set of stuff defines the “buckets” at the bottom of our “plinko board”- our “ballpark architecture”. We then take our features and while we implement them, we let the parts of our solution fall into our architectural buckets. This lets us have a set of basic working models, yet our architectural implementation evolves alongside the actual problem, not in a silo!!!

I am a HUGE believer in “co-evolution” of frameworks/ architectures evolving WITH the problems they solve. Building entire frameworks and architecture models detached from real problems just delays the learning. You learn on the day you start to USE the framework/ architecture model where you were wrong, what inconsistencies you have and what you REALLY need.

So – my 2 cents is – do not build in a silo. Use the Plinko architecture formula above for your basic architecture approach….

-Chris

Filed under: Agile Development,Developers,programming — chrisdrop @ 10:31

19/05/2007

Conquest through extreme composition + glue, Part 1

We are currently in a 2 week design spike. We are developing a solution with one primary goal:

Integrated User Experience

The product will be used to unify many .net based applications. The product must enable developers to deliver faster than ever to their trading clients. The product must provide radical levels of integrated user experience. We must go far beyond our simple “plugin model” if we are to provide the ability for peer plugins to be themselves extensible, for the host application to be itself extensible and for all participants to get maximal reuse.

Amidst the course of this spike, we are all coding a lot and talking a lot. The team has lots of smart folks with a collective ton of experience building desktop applications serving the hard demands of traders. We are trying hard to keep our deliverables “end user effecting” yet during the spike, we are basically focused on defining a basic set of architectural buckets (see plinko model) into which our end user effecting features will fall during implementation.

What do we really want?

  1. extensibility/ plugability
  2. reusability
  3. testability

I think the crux of it is:

  1. Really practicing composition
  2. Really practicing The Dependency Inversion Principle
  3. Sticking stuff together contextually – some glue
  4. … sort of an afterthought … Getting away from too much procedural programming hiding in OO code.

That is really it. We want to rely on abstractions and not know/ care about what our implementing parts need to have in order for them to work. We want to support The Open-Closed Principle by varying the behavior of our system by providing different collaborating implementors.

I am trying hard to help a lot of folks understand the need for The Dependency Inversion Principle. I am trying with step by step success to move lots of folks to really writing unit tests. I believe this:

  1. You start writing unit tests
  2. You earn the understanding of why you need The Dependency Inversion Principle
  3. You practice The Dependency Inversion Principle
  4. You get more adaptable software that is composition based
  5. You earn the problem that spring and other dependency injection containers solve – the need for “formalized glue” to stick everything together.

I have seen this evolution time and time again. In stead of “ramming this all down people’s throats” – I try to let people “earn their next problem”. As soon as people earn the next problem, they see the value of the solution at the next level.

Anyhow – this bunch of stuff says, ideally you are:

  1. Relying on abstractions
  2. Allowing your implementors to be given to you in stead of newing your concrete dependencies

Your abstractions typically have N implementors – a bucket of IThingable’s are available. This is plugability - the reliance on an abstraction and the ability to “inject” something along that seam. The isolation factors of The Dependency Inversion Principle gives you the testability. The fact that you have buckets of things that can be implemented at a level of abstraction + composition gives you the reusability.

This gives us a picture that looks like .. coming in part 2 :)

Filed under: Agile Development,Developers,programming — chrisdrop @ 16:23

03/04/2006

Rocky and Jeffrey battle on about Test Driven Development … and my 2 cents

There is yet another debate on TDD going on. Basically – folks do or do-not-practice TDD. The mindset of TDD is one that is useful in my thinking. I think too many developers – even quite good ones think; “I do not need to write tests”, or “It is not a good use of my *expert level* writing unit tests”. Here is why I disagree:

  1. It is true that better developer write better code.
  2. It is also true that better developers can turn out more code -they are more productive.
  3. It is also true that developers are people – therefore make errors.
  4. It is also true that *better* developers are the only ones on YOUR project.
  5. It is also true that software spends 80% of it’s lifecycle in maintenence.

This all means that there will be lots of code – errors to start with and that more and more code will change and be added (usually by people other than the original author). Tests are needed to maintain the integrity. When we make changes to software – we need to know if/ what we break. Tests are needed !
For reference – here is the chain of events that caused this post:

The instigation (Rocky), the chastisement (Jeffrey), the retort (Rocky).

These are interesting reads. In essence, Rocky is not much of a TDD guy. I will say that in general – I have not been much of a Rocky fan – not sure I really generally prefer his ‘way’. That being said – I can certainly understand some of what he has to say. I also respect him and I do not want to belittle that here. ‘Getting’ TDD takes time, effort and it is part of a whole picture. I think we NEED TDD- but I do not believe it stands alone as ‘the way, the truth, and the light’ of development.

Jeffrey on the other hand ‘gets it’ regarding TDD. I will add that on the whole – I tend to see eye to eye with more of Jeffrey’s ‘way’ (at least what he writes about). Jeffrey believes that TDD has added greatly to his bag of development tools, I agree there.

I will reply to 1 point:

Rocky thinks developers dont think test first.

I think that developers DO think test 1st – they just don’t know it yet. If they do not – they should. What I mean here is that when you are desiging a class – you should generally be thinking about how you WOULD LIKE TO USE THIS CLASS. This is the central idea that TDD helps draw out – when you are writing a class – think about how you expect to use it, write a test that would make that desired usage true, then make the class act as you would like it to ideally.

Practicing TDD helps you to focus on the desired usage of a class/ method. Without TDD- developers will focus on embelishing a class with all the right setters, extra convenience methods etc. These things add code and provide no value until they are required. At such a point in time, these methods should be added. This brings my 2nd point – that TDD helps keep your code LEAN. Since you are focused on just implementing what you need to use at the moment – you are not overcoding.

I will end by saying that TDD is NOT the only thing that can help developers change their mindsets. TDD – when used with Mock frameworks, when used with IoC, when practiced with a team that ‘gets’ all of those things is MUCH stronger than when used alone (although I do believe TDD when used alone is still useful). My point here is that TDD shines much brighter when it is used in an environment with accompanying practices and efforts.

The same can be said about IoC. Inversion of Control is most useful and it really does make your code more flexable. That being said – it ALSO works WITH TDD. It supports TDD- you can pass in mocks or other classes into your code to test it. IoC helps you write testable code. Without IoC – people must ask themselves “How can I test this” and then they can say “this is not testable”. This I believe is how a lot of TDD efforts get squashed. People practice TDD without the supporting practices.

Anyhow – that is enough for me for now.

-Chris

Filed under: Agile Development,Developers,programming,unit testing — chrisdrop @ 14:59

28/03/2006

Cowboy coder to developer

I am leaving the project that I am leading currently in a few weeks. Today I began handing off the lead to one of the developers on the project. The task of getting the entire team ‘on the beat’ of the project and keeping them there is key for this person to be able to maintain. One of the other developers was asking me today what he could read/ do to ‘totally revamp and update his code style’. In trying to introduce agile practices to a group – the group has a lot to change.

Some of the stuff that we introduced:

  • Mock objects (Rhino Mocks)
  • Unit testing (NUnit)
  • SpringFramework.net
  • log4net
    Design Patterns including

    • Model/ View/ Presenter based architecture
    • Strategy

      I sent him some of the books, articles etc. that I usually recommend. This chat however got me to thinking – what does it take to become a great developer? There are really 2 transitions that I was thinking about; the transition from a mid-level to a senior developer, and the transition from being a seasoned developer to a world class developer. In the past I have said that the central thing that I am looking for in a developer is someone who is effectively a ‘Good abstract problem solver’. I still think this holds true.

      That being said – there are some foundations that I typically look for in a developer – particular mostly to C# and Java developers, but much is also applicable to other development.

      Principals

          Design

            • Model domain in software – see Domain Driven Design
            • Learn the ‘classical design patterns’ – see GoF book and language specific variants

              Code level

                • Design by contract
                  • Assertions
                  • Guard clauses
                • Intention revealing interfaces – see Domain Driven Design
                • Effective class composition – single purpose classes and methods
                • Learn the Refactoring Patterns – see Martin Fowler

                  Language Level

                    • Understand the runtime you are working in
                      • garbage collection
                      • how the heap/ stack work
                    • Threading – deep understanding of concurrency issues
                    • Be able to program in at least a few different languages

                      Enterprise

                      • Understand Databases
                      • Understand messaging systems
                      • Understand XML
                      • Understand heterogenous as many system interoperation mechanisms as possible
                      • Understand web services
                      • Understand security concerns
                          • What does it take to be great? A thirst to learn. A thirst to experiment. Coding is what makes you learn. Working with smart people will help you learn. Doing ‘pet projects’ will help you learn. Stretch your ara of comfort all the time. If you think C is hard – do a pet project in it. If you are intimidated by C#, Java, Ruby, Web Services, ANYTHING – just try it – you will see how much more alike they all are then you think. You will also learn to love the differences and functions of all.

                            I will continue to update this as I need to run :)

                            -Chris

                        12/03/2006

                        An old yet still applicable article all developers should read (IMHO)

                        Object oriented software development is something that takes people time to get. Often I find myself pointing people to this this article to sum up why I am doing or something, why something feels right or wrong to me.

                        This is not a new article – I just find myself pointing people to this better explaination than I could give on more and more occasions.

                        Summary of principals:

                        The Open Closed Principle (OCP) ?
                        A module should be open for extension but closed for modification.

                        The Liskov Substitution Principle (LSP) ?
                        Subclasses should be substitutable for their base classes.

                        The Dependency Inversion Principle (DIP) ?
                        Depend upon Abstractions. Do not depend upon concretions.

                        The Interface Segregation Principle (ISP) ?
                        Many client specific interfaces are better than one general purpose interface

                        The Release Reuse Equivalency Principle (REP) ?
                        The granule of reuse is the granule of release.

                        The Common Closure Principle (CCP) ?
                        Classes that change together, belong together.

                        The Common Reuse Principle (CRP) ?
                        Classes that aren’t reused together should not be grouped together.

                        The Acyclic Dependencies Principle (ADP) ?
                        The dependencies betwen packages must not form cycles.

                        The Stable Dependencies Principle (SDP) ?
                        Depend in the direction of stability.

                        The Stable Abstractions Principle (SAP) ?
                        Stable packages should be abstract packages.

                        Filed under: coding,Developers,patterns and principals,programming — chrisdrop @ 20:22

                        17/02/2006

                        Developing User Interfaces…..

                        Inspired by an article linked @ SlashDot

                        I got to thinking about developing software for end users, as I often do….

                        My current project is a desktop credit derivatives trading application that ~900 users globally use (not too many I realize – but enough to be interesting). When I 1st came on the project the 1st thing that struck me was how poorly designed the user interfaces was – it was NOT apparent how to use it at all. We did have the opportunity to work on that… I have spent the recent time working on a new ‘trade blotter’ and general UI application architecture. One of my primary goals is, and will continue to be – making the UI feel like home to the end users. Making the UI really support the habbits, quirks and needs of the end user in a way that is not just ‘some fluff atop the “real” program’. The UI is the real program as far as a user goes. All the nice ‘backend processing’ in the world is great – 100% needed, but the UI is where you can get strong percieved wins from your end users.
                        Here are a few links for those folks that want to keep up on UI design practices and patterns. So many software developers consider the UI tier to be the fluff part that means the least. Unfortunately – the users (that pay for the development generally) think the opposite :)

                        welie.com
                        designinginterfaces.com (book site with refs)
                        Sari Laakso’s patterns
                        ..newer Yahoo!s UI patterns site

                        I will also mention that after a few years of doing larger class desktop application/ smart client development – I have seen the same issues and constructs come up over and over. 2 frameworks abstract smart client/ rich client/ desktop applications extremely well.

                        The 1st is the latest Microsoft CAB (Composite UI Application Block). This specifies excellent abstractions for common rich client application needs. When I was going over the internals – again and again I found myself saying ‘yes – we did that too’ or ‘wow – we solved that issue differently – you guys did it better!’. I will also note the Infragistics 2006.1 works directly with the CAB. Excellent move on their behalf!

                        The other is the Eclipse RCP (Rich client platform). I have been really studying out the guts of eclipse – the RCP in particular (while reading – The Java Developer’s Guide to Eclipse, 2nd Edition). What an excellent set of APIs these folks have come up with. The plugin architecture and the notion of ‘contribution based extension’ are particularly excellent.

                        -Chris

                        Filed under: c#,coding,Developers,java,User Interfaces — chrisdrop @ 17:42

                        16/09/2005

                        Hiring good developers is hard

                        I am trying HARD to hire people – and boy is it hard. (been doing it for years and it is still hard)Senior C# Developers in New York – here’s the catch – it is in Long Island – 45 min outside of NYC. MAN is it hard to get good talent out here. We HAVE an amazing group – world class developers, but MAN is it hard to get em’ out here. We have been doing great top 100 web site projects as well as really large smart client application development. It is all SOA based – exciting and great as dev work goes. I interview person after person, we have professional screening of candidates, many people work hard at this process. At the end of the day – when I am discouraged, we sometimes see those great developers – and I remember that they DO exist and I am re-encouraged. But BOY is it hard to get there.

                        Also hiring; QA Manager, Business Analyst, SQL Server DBA, 5 more C# Devs in early 2006. It is painful – because we are picky. I often get criticized for being too ‘tough’ on candidates, but – frankly – I am not. If people put something on the resume – I WILL ask about it. I find this amazing pattern – and it gives me a theory. Here it is…..

                        Theory of Most Desired Skills

                        My primary method of interview is to allow people to give their own context and talk freely. I say something like “So – what do you like to do in programming world? What are you good at doing? What do you think is key? etc.”. I find that SO often what happens is that people start talking about something they know less about than other things. So – my theory is that developers believe that the areas where they are most vulnerable, where they know the least or perceive as the ‘hardest’ – they believe this is what you want them to know. I have seen it so many times, that I just had to rationalize the pattern. I really believe that so many developers perceive the areas where they are weak to be the most important areas and they just lead themselves right into talking about those weak areas. This is of course awful for them. It hangs a large percentage of unqualified candidates.

                        One of my favorite interview hangs was with a gentleman who insisted that he was using XQuery. The problem was that there were NO implementations of XQuery at that point in time – just a W3C spec. In any case – he fessed up – what a joke!

                        Filed under: Developers,work — chrisdrop @ 12:57

                        Powered by WordPress