Google Website Translator Gadget

Friday, 24 June 2011

Elementary, my dear Watson

image

<rant> I don’t know about any other .NET developer out there, but I’m finding the current speculation with regards to what’s going to happen with vNext of the .NET developer tool stack to be totally frustrating to say the least.  This is causing so much angst and damage in the .NET developer community.  The uncertainty about what’s going to happen with technology stacks like SL, WPF etc. and the unwillingness of MS to be open about their future is killing a lot of momentum and goodwill and just adding more fuel onto the “oh-what-is-MS-up-to-now-again” discussions.  Yes, I know, all will become crystal clear at the BUILD conference somewhere in September, but why didn’t MS keep quiet until then?  Figure out what you want to do with the different technology stacks, restructure and get enough prototyping done BEFORE starting to communicate to the developer community.  Why even mention something like “HTML 5 and JavaScript is the way to go” with the first demo preview of Windows 8.  Surely MS should have expected the reaction by developers wanting to know what the future holds for the other technology stacks?  Anyway, I hope MS gets this right and that v1 of the next, seemingly consolidated UX platform, does not set us back another 2/3 years in waiting for it to become a really usable technology stack. </rant>

So until BUILD in September we are left to act as Sherlock Holmes – looking at information surfacing via leaked e-mails and other blog posts.  Alternatively we can just let it be and hope that everything will indeed fall together in a big “ah-hah moment” come September.  I just hope that an already fatigued .NET developer community will have enough energy left to buy into whatever MS is going to preach next and that it will be “Elementary, my dear Watson.  Elementary indeed.”  Time to get some rest before September then Disappointed

Monday, 11 April 2011

Pragma On Key Silverlight Localization

Globe

One of the big features that we are adding to Version 5.4 of On Key, Pragma’s Enterprise Asset Management System, is the ability to use the system in different languages.  It seems like the first language we will support in addition to English will be Brazilian Portuguese  to support customers for our Pragma Brazil service company.  So I’ve been spending some time during the past week or two looking at the various aspects of On Key that we need to localize to determine the best solutions for getting everything localized.  In this post I will cover some useful information I discovered in my research.

Monday, 04 April 2011

Pragma Software Development: Check-in Procedure

When working together in a software development team it is important to have a common definition for when something is DONE.  An important aspect of getting things DONE is a well-defined check-in procedure that all developers follow to commit something into the source control repository.  Here is the procedure that we use at Pragma for committing changes into our Team Foundation Source Control repository:

  1. Code has been integrated with a recent version of the code in the TFS repository – at least a version of the TFS repository on the same day.
  2. Code has been formatted according to our ReSharper Pragma Full Cleanup profile.  This automatically formats all code to follow the same formatting and layout standards.
  3. Code compiles without any compiler warnings.
  4. Code adheres to our coding standards - I’ll write more about this in a future post.  We try to automate the application of our coding standards (where possible) using tools like ReSharper.  Alternatively, use a code review checklist to quickly identify areas of concern. 
  5. No ReSharper code analysis Error or Warning violations (i.e. green square in scrollbar). Any violation needs to be identified and agreed upon. Suggestions and Hints can be ignored if deemed unnecessary.
  6. No FxCop violations. Any violation needs to be identified, agreed upon and justified using the in-code SuppressMessage attribute.
  7. New functionality has been covered by tests and the code coverage has been verified using NCover.
  8. Bugs have been covered by tests and verified using NCover.
  9. Code adherers to the Logging strategy and the developer has inspected the usefulness of the log statements using Log4View.
  10. Code adheres to the Exception handling strategy for managing exceptions.
  11. Error Messages and translations have been added to the resource files.
  12. The associated TFS work item (development ticket/task) has been updated to reflect the effort involved (actual hours, comments etc.)

Once the code satisfies the above mentioned criteria, the developer runs a gated check-in using the TeamCity Visual Studio Plug-in.  This ensures that all the unit and integration tests are executed by the TeamCity build server after integrating the local changes with the latest TFS repository changeset.  Only if all the tests pass will TeamCity commit the changes onto the Mainline.   The observant reader may have noticed that we don’t do an upfront code review.  As we work from home for 2-3 days a week, we conduct our code reviews on the checked-in artefacts.  I’ll write more about the code review procedure in a future blog posting. 

Lastly, for service pack development, the developer needs to consider whether the change needs to be merged across to the Mainline for the next major version and merge the changes across if required.

Saturday, 05 February 2011

Pragma Software Development Tools

Last time around I mentioned I would blog about the software development tools we are using.  They say a picture is worth a thousand words, so with time to blog being a bit short in the week running up to the final release of On Key, here’s  a mind map showing the different software development tools we are using in the different software development disciplines!  Btw, if anybody knows about a decent Live Writer plug-in to insert a thumbnail, be sure to leave me a comment.

Pragma Products SDLC Tools

Thursday, 20 January 2011

Pragma Software Development Team

20012011Following on my intention to blog a bit about our internal development environment here at PRAGMA, let’s start with a look at the software development team, how we communicate, where we work and what Software Development Lifecycle we follow.

 

Team

The software development team has grown quite a bit during the past 2 years.  Currently we have a Software Development Manager who takes the responsibility of managing the project, prioritizing the feature set, interacting with clients, ensuring the product vision etc.  Reporting directly to the Software Development Manager is a Development, Test and Analyst lead. They are responsible for managing the 13 developers, 3 testers and 1 analyst that compromise the rest of the team.   The management function forms only a small part of their responsibility as they are all hands-on, doing full-time development, testing and analysis together with the rest of the team.  We believe in a flat structure and in the team taking collective ownership for the solution.  As Development Lead, I share the overall responsibility for the architecture with another senior developer in the team.  We also have a Project Manager/Assistant who helps with administrating the project plan and also currently plays the role of SCRUM Master.

Communication

One of the benefits of working at PRAGMA is that we get to work from home for 2 days a week.  Initially I found it very hard to adapt to not having the whole team co-located.  Especially in the early stages of the project, where I had to do a lot of mentoring, I missed the simple “luxury” of pairing with a developer to illustrate some concepts or to fledge out a design on a whiteboard or through some code.  As the project progressed and things settled in terms of architecture and skills the issue became less of a problem.  I still feel a co-located team is the most productive setup, but there is also a lot of merit in allowing people to work remotely for a day or two in the week by giving them the flexibility of not having to commute into office every day.

When working remotely keeping in touch is obviously very important.  We use Skype for IM and VOIP calls to interact between individuals and small groups of people.  I specifically mention small groups as we struggled to use Skype for calls that involved the whole team.  The call quality was not good and people would frequently drop and had to reconnect to the conference call. This might be due to bad connections from the different ISP’s that the remote workers are using so your own mileage might differ.  Fortunately for us PRAGMA makes use of Interwise Participant for web conferencing so our daily feedback session currently involves a combination of using Interwise for visuals and PRAGMA’s normal teleconference facilities for audio.  This obviously incurs a bit of cost for the remote workers but it doesn’t nearly weigh up against the other benefits like not having to commute.  As the broadband scenario in South Africa is getting better and better we re-evaluate this setup every now and then to see whether we can’t get away with only using Skype.  For simple remote pairing/debugging sessions we find Microsoft SharedView to be an excellent solution.

Office Space

Our offices are located in the Bellville Business Park in the Northern Suburbs of Cape Town so fortunately we miss out on all city traffic.  We moved into our current premises end of November 2009 and the new, modern offices are equipped with a very nice canteen and other facilities that make working at the office a pleasure.  Of course there is some good, free coffee as well Smile  The seating inside the building is based on an open plan setup.  The software development team sit together in what is refer to as the Lab with each person having his/her own small cubicle.  This is a picture of my cubicle in the Lab.

18012011

The cubicle barriers are about 1.6 m high and allow you to work without being distracted when somebody walks by your desk.  This setup works quite nicely although there are some days that I feel the cubicle barriers should rather be taken down to create a feeling of more openness and to “increase communication” in the team. 

We have whiteboards against all the walls for design discussions and two small adjacent meeting rooms to the Lab for ad-hoc design discussions and meetings.  We also have our build monitors setup against a wall in the Lab that shows our TeamCity builds and other dashboard related statistics relevant to our ongoing development efforts. 

 18012011(001)

We will hopefully be replacing the two smallish monitors with one big monitor during this year to make it easier to read as we also use these monitors as an electronic SCRUM task board during our daily at-the-office SCRUM stand-up sessions.

SDLC

Talking about SCRUM, one of my first responsibilities when I joined the team way back in July 2008 was to look at adopting a more formal software development lifecycle.  I’m a firm believer in an agile development methodology and all the disciplines involved with doing agile development so we adopted SCRUM.  We went through quite a few Sprints trying out the different aspects of SCRUM to find out what works best in our environment.  After starting with 2 week Sprints we eventually settled on 3 weeks as our ideal Sprint length.  We tried Planning Poker for a few Sprints but eventually dropped this in favour of just estimating the tasks for a Sprint in Ideal hours.   We had some big debates about using Story Points versus Ideal Hours and how we should track our Velocity.  We took quite a long time to get a Prioritized Product Backlog in place and also struggled to map the backlog back into a project plan that was required due to immense pressure from a big international client.   We eventually got into some kind of SCRUM rhythm, but we still have quite a few areas where we want to improve on going forward. 

For a start I think we need to break the team into smaller groups that focus on specific functional areas of On Key.  We can then use a Scrum of Scrums meeting to discuss the areas of overlap and integration.  We also need to get better at breaking down the functionality in coarser tasks (or work items).  I feel we are breaking down our tasks into too fine grained work items and this causes unnecessary management overhead and also totally clutters the task board with too much detail.   I think a lot of this is as a result of us rewriting and expanding on an existing system, i.e. we have a very good idea of what is required, but I think we must still try and manage the work at a higher level.   This might ease the pain of integrating back into the project plan as well.   Having said all of this, we have mastered a lot of the technical disciplines (like continuous integration, TDD, automated acceptance testing etc.) required for agile development in place and we do succeed at delivering small increments of working functionality in our 3 week Sprint cycle.

Sprint

So how does a typical 3-week Sprint look taking into account that we work remotely for about half of the time?  The following 3 week roster gives a quick summary of the high-level activities involved:

Mon Tue Wed Thu Fri
At the office
Individual Planning and Design Discussions
At the office
Daily Scrum @ 10:00
Daily Build @ 22:00
Working remotely
Daily Scrum @ 10:00
Daily Build @ 22:00
At the office
Daily Scrum @ 10:00
Daily Build @ 22:00
Working remotely
Daily Scrum @ 10:00
Daily Build @ 22:00
Working Remotely
Daily Scrum @ 10:00
Daily Build @ 22:00
At the office
Daily Scrum @ 10:00
Daily Build @ 22:00
Working remotely
Daily Scrum @ 10:00
Daily Build @ 22:00
At the office
Daily Scrum @ 10:00
Daily Build @ 22:00
Working remotely
Daily Scrum @ 10:00
Daily Build @ 22:00
Working Remotely
Daily Scrum @ 10:00
Daily Build @ 22:00
At the office
Daily Scrum @ 10:00
Daily Build @ 22:00
Working remotely
Daily Scrum @ 10:00
Daily Build @ 22:00
At the office
Daily Scrum @ 10:00
Sprint Build @ 22:00
At the office
Retrospective @ 09:00
High level Planning @ 10:00
Demo @ 13:00
Design, Training @ 14:00
Drinks @ 16:00

Well, I think that’s enough for now about the overall work environment.  In my next post I’ll look at the Development Tools that we are using.

Friday, 14 January 2011

Pragma On Key Software Development Environment

As I mentioned towards the end of last year, we delivered an important Release 3 milestone of Pragma On Key V5.  We are currently working hard to further improve the application performance and to fix the remaining bugs with the aim of going live with a big international customer 1 March 2011.  For those unfamiliar with PRAGMA and On Key [Source]:

PRAGMA is a global engineering company providing physical asset management improvement services and products to our clients. We believe that the most important value derived from our service is peace of mind. A client's CEO and his production or service team can focus on delivering their own client promise, whilst we, along with the in-house maintenance team, take care of optimising the performance and longevity of their assets over the life cycle of those assets.

Pragma On Key is our homegrown Enterprise Asset Management System (EAMS). Apart from the traditional functionalities generally expected from an EAMS, it has a variety of sophisticated modules that allow the client virtual and real-time access to asset information.

We are based in the beautiful Cape Town, South Africa and we have customers across a wide spectrum of industries in South Africa and also overseas. 

We currently support two major versions of On Key:

  1. Version 4 – A Windows forms client/server application that runs on top of SQL Server as DBMS.  The application was developed using Delphi and has been in production for quite a few years already.
  2. Version 5 – A new web-based solution architected as a RIA application.  It uses Silverlight as presentation technology and a layered server architecture using .NET 4.0 on top of SQL Server as DBMS.  

Both versions support interfacing with other ERP systems like SYSPRO and SAP via custom interfaces that we build.  In addition to rewriting a lot of the V4 features onto V5, we also added some really nifty new features to provide our customers with great flexibility in managing their physical assets.  In V5 we also started creating a SDK that allows third parties to build additional services on top of the core On Key application platform.   

Besides these cool features in On Key itself, we have also IMO come along way in creating a solid software development environment within PRAGMA.  The team closed to doubled in size during the last 3 years (we are now 22 people) and we simply had to mature our SDLC practices.  There are of course still a lot of areas where we can and will improve on, but I think we have a good foundation to build on for the future.

I want to start a series of blog posts where I write a bit about our software development environment - reflecting on the work environment, what tools and development practices we use and also areas that we want to improve on in future.  I also want to spend some time writing about the design of some of the core features within On Key.   I don’t quite know how all of this is going to pan out and how many posts I am going to create, but off the cuff, here is a short list of areas that I want to cover:

  1. Work environment – Team Composition, Office Space, SDLC (Scrum), Typical Sprint…
  2. Development Tools – Source Control, Build Server, Wiki, Work Item Management…
  3. Development Practices – Check-in procedure, Code Reviews, Coding Standards, Code Analysis (Static/Dynamic), Code Generation, TDD…
  4. Build Automation – Versioning, Continuous Integration, Continuous Performance Testing, Build Pipelines…
  5. Testing – Automated Functional Regression Testing…
  6. On Key Architecture – Client Architecture, Server Architecture, Localization, Exception Handling, Logging, Security…
  7. On Key Features – Rule Engine, Validation Framework, Background Tasks, Rollout, Synchronization…

This list is quite long!  Time permitting, I’ll try and keep posting on some topic hopefully once a week.  Till later…

Monday, 03 January 2011

My 2011 Software Development Reading List

A wonderful 2011 for all!  I’ve not made many New Year resolutions, but one resolution that I do want to try and keep is to work through my library of ever growing IT books that have been gathering some dust on my desk and hard-drive.  In stead of spending time reading through blogs, I want to rather concentrate on broadening/sharpening my skills through working through some of my books.  I’ve got quite a few good books where I’ve only read some part of the book and I also want to complete these as well.  So without further ado, here is my list of IT books for 2011 that I want to read:

  1. [Partially Read] Release It!: Michael T. Nygard  - Excellent advise on getting and keeping your software running in production.
  2. [Partially Read] Architecting Applications for the Enterprise: Dino Esposito, Andrea Saltarello – A great resource for all budding architects and a book that I want to re-read to evaluate our current architecture against some of the best practices mentioned in here.
  3. [Partially Read] Continuous Delivery: Jez Humble, David Farley – Excellent advise on using build, test and deployment automation to manage your software releases.  We’ve got quite a good deployment environment at work as I’m a big fan of continuous integration, but it is always nice to read some further insights from experts to see what areas we can still improve on.
  4. The Art of Application Performance Monitoring: Ian Molyneaux – Performance monitoring is high on the agenda for our Enterprise Asset Management System (EAMS).
  5. Algorithms In A Nutshell: George Heineman, Gary Pollice & Stanley Selkow – Time to learn and brush up on the Graph, Search, Path finding and Network Flow algorithms.  I’ve got a sneaky suspicion that we are missing out on some opportunities to use better algorithms within our EAMS.
  6. Pragmatic Thinking and Learning: Andy Hunt – Time to figure out the best way to think about solving problems.
  7. Growing Software – Proven Strategies for Managing Software Engineers: Louis Testa
  8. Programming Ruby 1.9 (3rd Edition): Dave Thomas – Lots of people are raving about Ruby and I want to start learning why.
  9. The Ruby Programming Language: David Flanagan & Yukihiro Masumoto

Happy reading :-)