Sorry I’ve not been about for ages, been in hospital having a couple of operations (nothing too serious) and then recuperating, now i’m in the process of moving house so I’m stressed beyond belief.
I'll blog my way back gently. Just a short one to start.
Im not here to preach Agile or flame it either. Its just an observation from my humble perspective I'd like to get down on paper. I had a conversation online a few nights ago with an old friend (he wont mind me saying this) battling with some slipping agile practices. It made me realise how easy it was, as a developer, to get very short-sighted in terms of the customers needs, by getting wrapped up in processes and procedures.
When pressure from the customer to deliver a series of products gets heavier, the thought of the agile change control process can be daunting. Evolving requirements throughout the lifecycle may extend the initial expectations of the delivery of the first product. Delay of the subsequent projects in the pipeline can cause disappointment with the user even though the delay was incurred through their evolving needs. Incremental steps are all well and good and we can promote them until we’re blue in the face but the fact remains that the customer (versed or not in agile methods) wants to know a ball park date (if not a specific date) for the delivery of the solution they desire.
In order to prevent customer disappointment that dreaded word can become more and more common, ‘signature…’. I’ve found the key to constant devolving agile practices is to reassess the stakeholder involvement. Weighty change documentation can point toward the fact that not all parties were involved through the entire process. Regular demonstrations to stakeholders reduces the dependency on the multiple signature approach. Being burnt by the comment “But I never agreed that… show me what document I signed agreeing to that” has pushed the forms across departments across the country, demanding signatures from all types including those with no direct involvement nor interest in the system at stake. (Never had that feeling of running round the office madly collecting a hundred autographs 5 minutes before a deadline? That panic of finding someone was on holiday?!) Its important to also assess the attitude from the developer side, “You signed it therefore that’s what you get” developing a system based on a signature can be foolish, and can degrade relationships valuable to your business. Any way, enough of that rant.
Got a bit of extra cash? Maybe an electronic whiteboard with print out functionality could be a fix. Doodle away on the board during your update meetings with stakeholders and print it out/save it at the end. The presence of the individuals in the meeting could work just like a signature. ‘You were in the meeting where we discussed this, here’s the image.’ I got to play on one in a local school, back home, not so long ago. It was brilliant for maintaining concentration and I found far more accessible than a powerpoint presentation (especially because it reduces your meeting preperation time!!!)
Encourage fluidity. Enable developers to document what they think important rather that providing complex templates. If the information to be documented is small the template may be inappropriate, scare off the developer and the information may never get written down. I personally encourage a wiki approach. It allows developers to jot down important (or not) details that may be of use to others in the team. It becomes a valuable knowledge base and starts to work against the developer/documentation animosity. Use a tool that allows easy inclusion of images and links. Don’t push it either, forcing someone to document their processes and demanded to know why, at the end of the week, they’ve written nothing , can force staff into writing for the sake of it. Developing your teams ability to assess the more appropriate information and long term value of knowledge organisation is key.
Sorry its only a short blog and its been such a long time since my last one!!!
xxxxxx
So, Mix has started. I must say I’m very jealous. I even found myself looking enviously at a picture of the contents of the goody bag earlier....I must get a life.
Anyway... Work has started on our MVP migration. Even I was struggling to keep a smile on my face. It’s not the passive view per se that’s caused me pain today, it’s the unit and spec tests that go alongside it. As we’re not doing the whole enterprise app straight away, there’s still lots left structured the ‘old way’. So much pain was caused trying to get the ‘new’ and the ‘old’ to sit alongside easily.
The way we have decided to do it, is to start with the new pages first. Any new screens will use passive view. We will ‘upgrade’ the others as we go. With the addition of a new project to our solution, I set-to with enthusiasm. I’m still really nervous that the folder structure we’ve added in there won’t be extendable easily and a couple of years down the line our ‘successors’ will be moaning that it wasn’t properly thought through. But it really was, I promise. It’s just really difficult to predict the future. And when you’ve not got the experience of doing this with another enterprise app before you don’t even have hindsight to fall back on.
If anyone has a suggestion for a good set of folder names to structure the mvp project, I’d really appreciate that. Eg ‘presenters’, ‘views’, ‘models’ sub folders; ‘interfaces’, etc etc. I know it sounds really lame to be worrying about folder names in the grand scheme of things. But when it comes down to it, the folder structure is the first thing new developers to the application will see, and in an enterprise app making things as transparent as possible is key. It's not always about starting with the complicated things first!
On a lighter note, I have a bit of geek rivalry going on between me and a friend and a couple of people we know. Infact it was mentioned today that the ‘geek-gauntlet’ has been thrown down. :-) So what I want to know is how do you measure ‘geekness’, how can we know when we’ve won (as I’m sure we will). Do any of you out there think you are more geek than anyone else you know, and if so how have you achieved it? Lol. Any comments gratefully received. ;-)
Something quick to cover custom event handling whilst using passive view.
Lets assume we have 5 buttons on the page that have perform similar function when pressed. EG Searching the database for some names . I’m not going to cover the testing for this. Of course when we get to our presenter layer we don’t want separate code for each button…that’s a lot of copying snd pasting.
Consider this html
<input id="btnJohn" type="button" runat="server" value="John" />
<input id="btnJack" type="button" runat="server" value="Jack" />
<input id="btnJames" type="button" runat="server" value="James" />
<input id="btnJason" type="button" runat="server" value="Jason" />
<input id="btnJeremy" type="button" runat="server" value="Jeremy" />
Nothing fancy. I’m not feeling particularly imaginitive this evening, so I’m afraid I couldn’t think of anything more real world. lol
We’ll be inheriting the eventargs into a class of our own so that we can use a property, which will take the value of the button pressed.
Public Class NamedButtonEventArgs
Inherits EventArgs
Private mName As string
Public Property Name() As string
Get
Return mName
End Get
Set(ByVal value As string)
mName = value
End Set
End Property
End Class
So now to the aspx.vb page, make sure you’re calling your presenter in the page load.
Private Sub MyPage_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim presenter As New Presenter(Me)
presenter.InitView()
End Sub
Declare a generic event handler that will take our custom eventargs class
Public Event NamedButtonClicked As EventHandler(Of NamedButtonEventArgs)
Now create the onclick event. Set your args and raise your event.
Protected Sub btnJohn_ServerClick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnA.ServerClick
Dim args As New NamedButtonEventArgs
args.Name = "John"c
RaiseEvent NamedButtonClicked(sender, args)
End Sub
One for each button
If you havent created your view already, do so
Public Class MyPresenter
Private mView As IView
Public Sub New(ByVal view As IView)
If view Is Nothing Then
Throw New ArgumentNullException("view")
End If
AddHandler mView.LetterButtonClicked, AddressOf LetterButtonClicked
End Sub
Public Sub InitView()
End Sub
Private Sub LetterButtonClicked(ByVal sender As Object, ByVal e As LetterButtonEventArgs)
‘ do functionality of button clicked using the value of e.name
End Sub
End Class
**revised**
aka - How NOT to convince your team you know best about design patterns...
First things first, I'm no manager. I have little ability at showing tact,
I have the patience of....something with little patience,
and I tolerate being questioned poorly.
So spending time convincing people that design patterns and TDD are a good thing is something I may not have entrusted to myself.
But we are all here to learn, and such skills I must gain.
So this post is to allow me to get my progress and thoughts down on paper.
Who knows there may be a nugget of info buried in here that someone else may find interesting, otherwise feel free to find amusement in my ineptitude.
So how do I sell patterns? A key factor is speedy understanding and communication.
Time can be wasted trying to explain to everyone the problem faced in an application.
Knowing an appropriate pattern can mean the entire team, in a few words, understand the problem, and know the exact course of action to solve it.
And even if that pattern was not widely known by everyone, just knowing the name brings them a step closer to being able to research it for themselves.
In my opinion, being able to categorise solutions already implemented with speed, makes the development process massively more agile.
Patterns have evolved through the mistakes made over years,
so what’s the point coming up with your own solution, why shouldn’t I rob....I mean 'borrow'...the results of lessons learned by those with far more experience than me.
Another key point would be to open the pattern discussion for anyone to put their opinion forward.
You never know, there could be an alternative you hadn't thought of that could be a valid contender to the design you had decided upon.
Free thinking can encourage enthusiasm for a project, a feeling of input and worth. We made the decision of Passive View.
I've been considering different learning techniques to try work out the best way to demonstrate this mvp pattern in practice.
I fell across the 'Four stages of Competence' psychological skill progression matrix
(its full of big words - I couldn’t help myself!) http://www.businessballs.com/consciouscompetencelearningmodel.htm
It surmises that there are four skill levels. The level we should be aiming toward for everyone in the team is at least a three:
1. Unconscious Incompetence -->
Team member is unaware of what they know regarding patterns, no interest in skill improvement, or unaware of need for improvement.
To move the team away from this mindset they must be made aware of the need for improvement,
demonstrate to them the benefits of applying patterns.
2. Conscious Incompetence --> Team member is aware of patterns, and their lack of knowledge in the area through trial and error.
Ideally they will now make a commitment to learning new skills in this area.
3. Conscious Competence --> After research and practice the user can apply their knowledge without assistance although not yet second nature.
Practice, practice, practice.
4. Unconscious Competence --> Finally the skill is second nature, like driving.
Another aim for me is show objectives being met.
Demoralisation is so easily achieved if we blindly move through code, refactoring where we can, with no short term goals to meet.
My aim is to try to help to break the task into smaller objectives so achievements are more easily commended
and direction is more easily marked. Good work should be reflected on and praised, as it’s easy to forget the goals reached once they have passed.
Sitting back and assessing how far you've come can really boost confidence.
kirsty
Don't get me wrong, I'm not one of these feminist types.
However, as one of the relatively few female developers in the industry, I felt it my duty to try to put into words the way I see it.
I got into development completely by accident. It was never offered to me as an option throughout my education. My degree was in business and IT because I quite fancied the idea of management. But even then, there were only four girls including me and 40+ lads. If you'd asked me back then what I thought a software development team would look like I would have described a small team of nerds doing 18+hour shifts out of choice locked in a dark damp room surrounded by banks of monitors and sci-fi memorabilia. No home life and possibly all still living with their mums. I think the Hollywood stereotype has a lot to answer for. Why the hell would any woman sign up for a job like that?
Usually I don't like to distinguish the difference in sexes in IT, I've always been a believer that it doesn't matter.
I don't struggle at my job or finding new jobs for that matter because I'm female, neither do I find it easier than others. And I certainly don't feel that I struggle to get pay rises because of my sex.
But the one thing that is starting to stand out to me over all other factors is the social side of it. My female friends are those from other teams or companies, people I've met outside of work, from university for example. Don't get me wrong, I have some fanastic relationships with my male colleagues, but I'm often left a little jealous of not having someone to have the same rapor with, as they do with each other. But on the plus side, the rarety of women in IT makes me feel a little like a minor celebrity at times. Dev Week last year was amusing, I got far more attention than I would have done on a regular Friday night out.
I'm rather more lucky than some, at my current company we have quite a few women in the department even if they do tend to be analysts or testers.
I think some people still struggle with coming to terms with the materity thing. 6 months off pretty much leaves you out of the loop with the speed technology moves. And I have to say I completely agree, I'm 24 and have absolutely no intention in the near future of having kids because I value my career. And until I've done the initial learning and Im at a job level with little promotion opportunity left, I cant see me changing my mind. Im jealous of men ony having to take a week off for paternity. With videoconferencing becoming more widely adopted I can see a way around the detatchment from work during maternity
Im here to fight for the cause to get girls into software dev. And girly girls at that. I've seen too many women surrounded my men for so long in IT, it seems their very femininity is being sucked out of them.
So here's to me, a rare breed.
Have a read of this:
http://intellect.computing.co.uk/2007/11/grappling-with.html
:-)
More Posts