C++ was originally developed as an extension to C for abstract data types (ADTs) long before OOP was king. One of my favourite books on the history and inner thinking of C++, although dated, was "The Annotated C++ Reference Manual" by Margaret A Ellis and Bjarne Stroustrup because it explained why certain design decisions were taken. What were the language designers trying to address by various forms of syntactic expression.
The problem with C++ is that it's a non-standard standard. There are many compilers each with different extensions and levels of support for the latest standard.
The trick is that whilst Java and .NET have become king of OOP they just don't replace C++ for all the reasons you want C or C++. There's something to be said for native code that is fully compiled and linked and doesn't require tens of megabytes worth of runtime environment just to run.
There is the D language but this hasn't gained wide acceptance, yet. Objective-C has been around for a while but also hasn't strayed far from being Next/Apple centric.
The time has come for a development community push away from C++. Away from its obscure syntax (eg, templates with specialisation or partial specialisation); from the inconsistent support of standards (compare MS Visual C++ with GNU C++ or Sun Dev Studio); from its limited set of reusable code (compare the opensource libraries available for Java against C++).
Like minded IT professionals I call on you to discuss collectively what would it take to move from C++? What do you need? want? deserve in a language?
Thursday, 13 December 2007
Tuesday, 9 October 2007
IT Projects: Leadership > Process
People talk about the failure rate of IT projects. Those who have a process to sell will tell you their process will save you and help you deliver the project on time and to budget. I've never seen that happen. Processes just help your bookshelf look busy.
A lot of time has been not just spent but utterly wasted defining different ways to assess project size - COCOMO (Constructive Cost Model), Function Points etc - and even more has been wasted describing software development and delivery processes: RUP, Agile, XP, dX (hybrix of RUP & XP), ISO 9000 derivatives and the generic patterns: waterfall, iterative and so on.
If half the time spent on this had been spent on encouraging good leadership and management practices, there would have been a great deal less software project failure. What's more, it's fairly likely that most IT teams would have been twice as effective on average at least.
Part of the problem is that most IT managers were once IT team leaders and those team leaders were once developers, testers, business analysts etc. The issue is that very few of the IT disciplines help you develop any sense of effective leadership or communications skills but somehow they become leaders and managers.
The classic Dilbert "pointy haired boss" or PHB is either a manager who has come up from a business background with no concept of IT or is an ex-IT worker with no concept of management/leadership. The business type has no appreciation for the creative element of IT work - why it's important to have time to create solutions or what's involved. The ex-IT type has no idea how to inspire people to be creative or appreciate the business point-of-view.
This is not leadership - it's leaderlack!
With leaderlack like this is it any wonder so many projects lose direction; forget their primary goal; overspend; under-budget or underestimate? Of course not. When you think of it in these terms it's almost obvious.
Having said all this there is value in processes but the value needs to be toned down. Buying into Fred's "super process" (be it XP v2 or RUP jazzed up) isn't going to sprinkle magic dust on your leaderlack project and make it work but it might help you keep the stakeholders engaged and informed. XP is all about keeping things to bite-sized chunks and making it ever tangible to the business rep as well as keeping a business rep involved. RUP is similar but broader - allowing for a broader software development stroke and making more open to the business rep when they decide to get involved.
Project management practices/processes like Project Management Institute's PMBOK does actually contribute to keeping a project on the straight and narrow but only if leadership is effective. Having good practices for issue and risk management; effort estimation and progress reporting is naturally going to help ensure a project's budget is better spent. Again, however, leadership is required between the PM and the team developing, testing and implementing the software solution for it to work.
In short:
A well led team can achieve a great deal. A badly led team can spend a lot of money.
Leadership, in this context means:
Good leaders are also the vanguard of the team. They protect it from external threats but also lead it to ensure it serves the team's overall interests as best it can.
In twelve years as a professional, I've seen way too many IT projects with too much focus on process - even if it's just "this is how we do it here" - and absolutely no effective leadership. I've since learned not just how to lead teams but how to help others develop their leadership skills.
It can be immensely pleasing to lead a team well and see the members thrive in that team!
I'm not sure the same can be said about processes.
A lot of time has been not just spent but utterly wasted defining different ways to assess project size - COCOMO (Constructive Cost Model), Function Points etc - and even more has been wasted describing software development and delivery processes: RUP, Agile, XP, dX (hybrix of RUP & XP), ISO 9000 derivatives and the generic patterns: waterfall, iterative and so on.
If half the time spent on this had been spent on encouraging good leadership and management practices, there would have been a great deal less software project failure. What's more, it's fairly likely that most IT teams would have been twice as effective on average at least.
Part of the problem is that most IT managers were once IT team leaders and those team leaders were once developers, testers, business analysts etc. The issue is that very few of the IT disciplines help you develop any sense of effective leadership or communications skills but somehow they become leaders and managers.
The classic Dilbert "pointy haired boss" or PHB is either a manager who has come up from a business background with no concept of IT or is an ex-IT worker with no concept of management/leadership. The business type has no appreciation for the creative element of IT work - why it's important to have time to create solutions or what's involved. The ex-IT type has no idea how to inspire people to be creative or appreciate the business point-of-view.
This is not leadership - it's leaderlack!
With leaderlack like this is it any wonder so many projects lose direction; forget their primary goal; overspend; under-budget or underestimate? Of course not. When you think of it in these terms it's almost obvious.
Having said all this there is value in processes but the value needs to be toned down. Buying into Fred's "super process" (be it XP v2 or RUP jazzed up) isn't going to sprinkle magic dust on your leaderlack project and make it work but it might help you keep the stakeholders engaged and informed. XP is all about keeping things to bite-sized chunks and making it ever tangible to the business rep as well as keeping a business rep involved. RUP is similar but broader - allowing for a broader software development stroke and making more open to the business rep when they decide to get involved.
Project management practices/processes like Project Management Institute's PMBOK does actually contribute to keeping a project on the straight and narrow but only if leadership is effective. Having good practices for issue and risk management; effort estimation and progress reporting is naturally going to help ensure a project's budget is better spent. Again, however, leadership is required between the PM and the team developing, testing and implementing the software solution for it to work.
In short:
A well led team can achieve a great deal. A badly led team can spend a lot of money.
Leadership, in this context means:
- having one or more people given the authority to lead the team; and
- reduce uncertainty for the team;
- communicate with the team as a collective and one-on-one;
- take time to appreciate what motivates the team members;
- constantly checking in with each member to ensure they have what they need to do their job;
- ensure each member has enough challenge and enough support;
- make reasonable promises and deliver each and every one.
Good leaders are also the vanguard of the team. They protect it from external threats but also lead it to ensure it serves the team's overall interests as best it can.
In twelve years as a professional, I've seen way too many IT projects with too much focus on process - even if it's just "this is how we do it here" - and absolutely no effective leadership. I've since learned not just how to lead teams but how to help others develop their leadership skills.
It can be immensely pleasing to lead a team well and see the members thrive in that team!
I'm not sure the same can be said about processes.
Friday, 29 June 2007
XML = XML parsers are Mostly Lexers
XML Parser - that's an oxymoron.
APIs like SAX and DOM do not parse XML for final consumption. SAX, in particular, performs lexical analysis, handing up tokens to another program to parse.
To illustrate : say you wish to parse an XML document that is quite hierarchical and can even be recursive. You need to write a program that can either handle tokens from SAX or delve (possibly recursively) into a DOM model. The code that does either is the real parser. The XML APIs just deal with text characters.
XML APIs are now quite sophisticated. They will validate against schema or DTD. They'll ensure the text being processed is a properly formatted XML document. They'll deal with entities and entity references; namespaces and comments. This is all great but the true parser is the program that drives all this. The bit of code that 'understands' what the text is all about.
While we're here discussing XML - it has its benefits but not everything needs to be XML. There are some situations where XML is worse not better. Programming languages for instance.
APIs like SAX and DOM do not parse XML for final consumption. SAX, in particular, performs lexical analysis, handing up tokens to another program to parse.
To illustrate : say you wish to parse an XML document that is quite hierarchical and can even be recursive. You need to write a program that can either handle tokens from SAX or delve (possibly recursively) into a DOM model. The code that does either is the real parser. The XML APIs just deal with text characters.
XML APIs are now quite sophisticated. They will validate against schema or DTD. They'll ensure the text being processed is a properly formatted XML document. They'll deal with entities and entity references; namespaces and comments. This is all great but the true parser is the program that drives all this. The bit of code that 'understands' what the text is all about.
While we're here discussing XML - it has its benefits but not everything needs to be XML. There are some situations where XML is worse not better. Programming languages for instance.
Wednesday, 20 June 2007
Less threads more Juice
Multi-threaded programming is cool. It's concurrent. It's how you make use of multiple cores or multiple CPUs or, hell, let's face it - it's how you squeeze just a little more out of the machine, programmatically.
What I find challenging to explain to people is that more threads doesn't mean faster software; or software that does more. It's particularly hard to convince people when they see J2EE servlet spec forcing a thread per TCP connection on you as a model.
In a nutshell, a CPU can only give 100% (unlike humans which can give 110% when the employer is either really good or really pushy). There are times where a CPU that would otherwise be idle but can do useful work. Like when an I/O operation is being done by a DMA controller. That's still not more than 100% - that's just not letting the I/O operation take some of the CPU time.
So the point in this is, that more threads just means that the 100% of total available CPU time for a system just gets spread around at the cost of more OS scheduling. This means there is less total CPU time available for user-mode software because the kernel is busy trying to manage the threads.
For those that must see a formula to get an idea, it might go like this:
C : total CPU time available to run a useful program, like a web server
t: number of threads in the system.
s: time taken by operating system to switch from one task to another.
Note: s is multiplied by 2 because the OS switches from one task to the task under consideration; that task runs for some period (usually 10ms); and then the task is suspended and switched to a whole other task. This is rough, of course, and assumes that thread priorities are equal - which they're not - some may be spawned more equal than others.
So, if you want to write software that is high-performance but deals with a great number of contexts, use finite state machines or Command Objects - that's a pattern folks - or do something other than use threads to separate contexts.
An example can be cooked up if comments require it...
What I find challenging to explain to people is that more threads doesn't mean faster software; or software that does more. It's particularly hard to convince people when they see J2EE servlet spec forcing a thread per TCP connection on you as a model.
In a nutshell, a CPU can only give 100% (unlike humans which can give 110% when the employer is either really good or really pushy). There are times where a CPU that would otherwise be idle but can do useful work. Like when an I/O operation is being done by a DMA controller. That's still not more than 100% - that's just not letting the I/O operation take some of the CPU time.
So the point in this is, that more threads just means that the 100% of total available CPU time for a system just gets spread around at the cost of more OS scheduling. This means there is less total CPU time available for user-mode software because the kernel is busy trying to manage the threads.
For those that must see a formula to get an idea, it might go like this:
C = 100% - 2.t . s
C : total CPU time available to run a useful program, like a web server
t: number of threads in the system.
s: time taken by operating system to switch from one task to another.
Note: s is multiplied by 2 because the OS switches from one task to the task under consideration; that task runs for some period (usually 10ms); and then the task is suspended and switched to a whole other task. This is rough, of course, and assumes that thread priorities are equal - which they're not - some may be spawned more equal than others.
So, if you want to write software that is high-performance but deals with a great number of contexts, use finite state machines or Command Objects - that's a pattern folks - or do something other than use threads to separate contexts.
An example can be cooked up if comments require it...
Tuesday, 19 June 2007
What is TechnoFu?
No idea. Just made it up. Actually, it's not that random at all.
I'm interested in technology and martial arts. I don't practice them both at the same time. It's really hard trying to perform kicks and punches with a laptop strapped to you but I have devoted many hours to both...
Kung Fu, generally, means skill. As my instructor used to tell me, "you can have kung fu in cooking. Wu Shu is the proper Chinese term for fighting arts."
So... perhaps TechnoFu is really any technical skill one can learn, think up or pass on.
Hopefully, in writing stuff here and seeing if any comments turn up, some of this might just happen.
Who knows?
I'm interested in technology and martial arts. I don't practice them both at the same time. It's really hard trying to perform kicks and punches with a laptop strapped to you but I have devoted many hours to both...
Kung Fu, generally, means skill. As my instructor used to tell me, "you can have kung fu in cooking. Wu Shu is the proper Chinese term for fighting arts."
So... perhaps TechnoFu is really any technical skill one can learn, think up or pass on.
Hopefully, in writing stuff here and seeing if any comments turn up, some of this might just happen.
Who knows?
Subscribe to:
Posts (Atom)
