|
I have used Xamarin extensively, check out my articles on here relating that technology. And exactly the same argument can be made there too. Whilst it takes care of the common functionality nicely, you still need to create separate assemblies for each of the platforms where you want something specific.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
After considerable effort and much re-work, re-design and re-architecting, the apps I have been working on have eventually been released to the app stores (Windows, Android and Apple). The original apps were in fact responsive web pages and were simply iFrames that linked to these web pages. Whilst this was sufficient in the short term to simply get a mobile presence and to be able to tell customers "We have an app", as a long term strategy it was not sufficient. Especially if you wanted to harness any of the native functionality of the devices.
So the decision was taken to completely re-develop the apps in a technology of our choosing. We went for Telerik Platform as it gave us much more than just a development platform.
- a testing platform
- data access
- notifications
- extensive plugins
- business services platform
- analytics and crash reports
- feedback
- user-management
and many other benefits.
So I took the original apps and completely re-developed them using Telerik Platform, which involved using Kendo UI, javascript, the MVVM pattern and Apache Cordova. The direction we took was to go hybrid so we have one code-base for all the mobile platforms.
Last week we released the apps to the apps stores and customers have been downloading and using them, which is a great feeling.
We still have many features we want to add to the apps, so they are still a work-in-progress. But for now, we're going to let people use them and wait for any feedback we get.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Following on from Five Truths about software development III[^]
1. When you've checked in all your code and feel all smug as you wait for the rest of the team to finish their work for the sprint, you realise that 6 new bugs have been raised needing your attention before the software can be released. Suddenly you're the bottleneck.
2. When the only estimate you can give to the project manager is "How long is a piece of string".
3. The terror you feel when you have to upgrade your development environment in case it breaks something.
4. Triple checking the question you're about to post on Stackoverflow as you just know there's going to be some smart asses who wil pick your question apart or just plain downvote it.
5. The buzz you feel when you finally fix that bug that's been evading you for days
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Following on from my earlier post Could this function be unit tested without modifying it?[^] the simple answer is yes it can. In this post I will explain how.
To summarise, the function that caused the problem used the current date to make a particular calculation using DateTime.Now . The original unit tests I wrote one day and all passed, then subsequently all failed the very next day as the function was returning a different result based on the current value of DateTime.Now .
My initial approach was to pass in a default value for the date. If no date was supplied then DateTime.Now would be used. Otherwise the supplied DateTime argument would be used. But I wasn't keen on this approach. Supplying default arguments to functions just so they can be unit tested had a bad code smell.
I had a look at the Pex and Moles[^] framework which supports unit testing by providing isolation by way of detours and stubs by allowing you to replace any .NET method with a delegate. This sounded pretty cool and I very nearly took this approach.
In the end however, I opted for a Dependency Injection approach. The benefit of this approach is that it forced me to refactor the code to make it less reliant on the environment, and that's a good thing.
In the code snippet below you will see I have defined an interface called IDateTime which contains one property called Now of type DateTime . The class ReportLibrary then contains a reference to this interface called _datetime . A private class called ActualDateTime implements IDateTime .
We then need to define a default constructor and an overloaded constructor (as we will pass in the required DateTime in the constructor). If we create an instance of the ReportLibrary class with no parameters (as our application will do) then the value for _datetime is defaulted to DateTime.Now . If we pass in a value to the constructor (as our unit tests will do) then we assign that value instead to _datetime .
namespace CoreLibrary
{
public interface IDateTime
{
DateTime Now { get; set; }
}
public class ReportLibrary
{
private readonly IDateTime _datetime;
private class ActualDateTime : IDateTime
{
public DateTime Now { get; set; }
}
public ReportLibrary()
{
this._datetime = new ActualDateTime { Now = DateTime.Now};
}
public ReportLibrary(IDateTime datetime)
{
this._datetime = datetime;
}
public int MyFunction()
{
int result;
DateTime today = this._datetime.Now;
return result;
}
}
}
So here is how we will invoke the function from the application.
ReportLibrary reportLibrary = new ReportLibrary();
int result = reportLibrary.MyFunction();
And here is how we invoke the function from the unit tests. Firstly we need to define a class that implements our IDateTime interface. Define this at the top of our unit test class.
[TestClass]
public class ReportLibraryTests
{
private class MockDateTime : IDateTime
{
public DateTime Now { get; set; }
}
}
Then in the test method we create an instance of this class and assign the Now property with the required value for DateTime.Now .
[TestMethod]
public void MyFunctionTests()
{
IDateTime dateTime = new MockDateTime();
DateTime today = new DateTime(2016, 8, 3);
dateTime.Now = today;
ReportLibrary reportLibrary = new ReportLibrary(dateTime);
int result = reportLibrary.MyFunction();
Assert.AreEqual(999, result, "Invalid result for 'MyFunction'");
}
And that's how I managed to isolate the function so that it works both in the application without any modification to its signature, and in the unit tests whereby different values for DateTime.Now can be supplied
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I have been writing a lot of unit tests recently, as we move the business logic from our reports into business objects that are then invoked by the reports. To ensure that the migrated business functionality works as expected, I've been writing unit tests to ensure that this is the case.
I came across one particular function recently that had my head scratching. The unit tests I wrote that invoked this particular function all worked yesterday, but then they all broke today. A quick scan through the code highlighted the obvious issue. The function returns the estimated mileage for today, given certain parameters. The function therefore determines what today is (the function is written in C# and so uses DateTime.Now ). So obviously the values returned from this function will return different results every day.
Without modifying the code to the function, I was wondering if there was any way to unit test this particular function. The solution I went for in the end was to pass in a default value for today. If no value for today is passed in as a parameter (which is how the function is invoked by the reports) then today is assumed to be....well....today If a value is passed in for today (as is the case with my unit tests) then this value is assumed to be today.
The concern for me was that I had to amend my function to accommodate unit testing. Surely I shouldn't have to amend a function just so it can be unit tested.
Which got me wondering. Is there a way around this particular problem? Are there other scenarios where a change needs to be made to a function to accommodate unit testing?
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
To answer my own question, the answer is yes....it is possible to fake (or mock) any .NET method using delegates using Moles as in the Pex and Moles[^] framework.
Here's an example[^] of exactly what I need
Pretty cool
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I have spent many years working with various build tools, with a particular emphasis on creating continuous integration (CI) environments. I have worked with Nant, MSBUILD, Cruisecontrol.NET, TeamCity, Git and Subversion to name a few. I have configured automated tests as part of the build process using Nunit and automated the signing and packaging of an Android app, all using various build and CI tools.
So I have a pretty good understanding of the build process and the tools and environments that support it. For this reason I haven't used the Application Lifecycle Management (ALM) features found within Team Foundation Services (TFS) as I haven't found them to be best-of-breed. However, that was then, and this is now. I've recently been using the latest build features in TFS 2015 and have to admit that I'm very impressed with them.
They are very much improved from previous versions of TFS. One of my biggest criticisms was that TFS only really worked within the Microsoft build tools ecosystem, and didn't play particularly well with other build tools and systems. That's all changed in TFS 2015 though. The build tools in TFS 2015 now support practically any build tool or platform you care to mention. Git, Maven, Nant, Android, iOS, scripting languages etc. The list of supported tools and platforms is extensive and impressive.
I managed to get a complete build setup and configured with ease. This included a full build, continuous integration triggering from TFS and a deployment to our development server. From code being checked-in to being deployed on the test server is all automatic and takes just a few minutes to run.
This is an ideal build solution for anyone looking to automate and simplify their build process and which is capable of supporting many different build tools and platforms. The Rolls Royce build solution is still TeamCity, but this an impressive build platform nonetheless and one that I am happy to keep using.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I've recently been using Telerik Platform for mobile development, so I thought it may be useful to give an overview of my experiences, especially as I've previously used Xamarin for mobile development.
For those that don't know, Telerik Platform is a complete mobile development ecosystem consisting of a suite of Telerik technologies rolled into a single unified platform. There are tools for development, testing as well as backend services such as data services, email / SMS services and business logic services, analytics and user management. All of these are accessed from your Telerik Platform account (depending on your subscription level of course).
The backend services may be implemented in your app using any combination of the folling APIs and SDKs.
- Javascript SDK
- .NET SDK
- iOS SDK
- Android SDK
- RESTful API
As can be seen, all mobile platform development environments are available to the developer.
All the tools you need across the entire lifecycle of your mobile app are all accessed from a single location. Unlike other development platforms, Telerik Platform is more than just a development tool, it contains the full complement of tools to manage the entire lifecycle of your app.
There are two key options to choose from when deciding how to build your app. You can choose either a hybrid app or a native app. I won't go into the pros and cons of the different approaches as this is beyond the scope of this article. Suffice to say that if you opt for a hybrid app you are using Apache Cordova. If you opt for a native app you are using Telerik NativeScript. In my case I was building a hybrid app. The reasons were as follows:
- We wanted to target all mobile platforms (at the time of writing NativeScript does not support Windows Phone)
- The app was fairly straight-forward with limited access the device's capabilities
- The learning curve was less steep due to the fact that a hybrid app employs web skills such as HTML, CSS and Javascript, all of which are familiar to me. The areas where I was less familiar was with using Telerik's Kendo UI components and the underlying MVVM architecture. Thankfully there are numerous examples and documentation, and being a competent web developer I picked these up fairly quickly.
The backend services are really a powerful addition to the development experience. The option of using these from the cloud reduces the reliance on local infrastructure, such as data and email servers. You can build your entire app from their cloud portal. There is a Visual Studio plugin you can download, which is useful, but I predominantly used their cloud portal.
One of the best things I enjoyed about Telerik Portal is their AppBuilder technology. This allows you to test your app in a simulator with varying combinations of platform (Apple, Android, Windows) and screen resolutions. And best of all, you can download the app to your own device using the Telerik development apps. Building your app generates a QR code. This QR code is then scanned using your device using the Telerik development app, which then copies the app to the device. No pesky USB cables or installing/configuring emulators are required. This is a genius piece of technology. Your code changes are reflected immediately in the simulator, and can be tested on the physical device by simply swiping the Telerik development app. From coding to testing on a physical device has never been simpler.
All in all I have been very impressed with Telerik Platform, and would certainly recommend that it be included on your list of candidate development platforms if looking at going into mobile.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
modified 8-Jul-16 15:42pm.
|
|
|
|
|
Whilst recently investigating various mobile platforms with a view to making a decision as to which of the many mobile technological ecosystems we should opt for, it became clear that what was really needed was some direction from the business. Without a full appreciation of where mobile fitted into the company's overall business strategy, it was impossible to gain any real traction on the problem.
For example, having definitive answers to questions such as these is important.
- What are the company's overall corporate objectives?
- How can a mobile initiative help the company in meeting these objectives?
- What does the company hope to achieve by using mobile technology?
Before making any decisions regarding mobile technology, it's important to unsderstand as clearly as possible how the mobile strategy is aligned to the overall business strategy. If the two are not aligned, then do you really need a mobile offering in the first place? Assuming that you do need a mobile offering, it should be clear where it fits into the overall business strategy.
Before embarking on a mobile strategy, it may be useful to know how many of your existing customers are currently using the web version of your application (assuming you have one). This will give you hard numbers to help sell the idea to other areas of the business. It will also tell you what devices your customers are using you so know what mobile platforms to target.
It may be the case that all you need is a responsive web site which can then be packaged for the required mobile platforms. This is a good first step onto the mobile landscape without incurring the costs of going full blown mobile. From here, you can then gauge how your app is received and decide what next steps to take (if any).
The key is to ensure you have a clear business strategy and that the mobile platform forms a cohesive part of that strategy. Going mobile just for the sake of it is not a strategy.
Going mobile needs to align with the overall business strategy to stand any chance of success.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Well I'm currently working my notice with my current employer and start my new career next month. I'll be building responsive web sites and hybrid mobile apps using tools including Bootstrap, Telerik Platform and Cordova. These are technologies which I am not familiar with so I'll have to get learning. I'm at least familiar with web technologies (HTML5, CSS3 and Javascript) so this at least gives me a headstart on building web enabled pages.
Having previously used Xamarin.Android to build cross-platform mobile apps, it will be interesting to see the differences in building, testing and deploying hybrid mobile apps.
Should be fun. Exciting times ahead
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
|
Hmmmm maybe I ought to post this in the Lounge lol
Great article, I've bookmarked it so I can read it later
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
In this article[^] the author discusses the relative pros and cons of hiring someone who has attended a bootcamp (a short but intensive course) versus a college graduate. Like everything in life, neither is simply better than the other as it depends on what you are looking for.
First off, neither is likely to have much (if any) real-world industry experience, so on that basis they are evenly matched. If you are looking for a solid programmer, and are not necessarily looking for them to rise up the career ladder into more technical positions, then a bootcamper would be an ideal choice. If however, you are looking for someone with a greater depth of skills (particularly theoretical skills) who will contribute more in the future, then a college graduate is an ideal choice.
What the bootcamper may lack in theoretical knowledge they make up for in practical knowledge.
The choice between the bootcamper and the college graduate depends on what you are looking for. It would be unfair to say that one is better than the other as that simply wouldn't be true. As usual, context is important.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I was recently reading this Why I Hate Best Practices -- Visual Studio Magazine[^] and it struck me that the title was mis-leading. In the article, the author makes the case that best practices are general rules and principles that have been demonstrated to work in practice, but that they shouldn't be rigidly followed.
This is a fair and reasonable point (although the example he gives to justify his point is not particularly well thought out). A best practice is just that. It's guidance only, not a rule. For certain specific problems, implementing the best practice may not be appropriate. Blindly following best practices can sometimes be counter-productive.
So whilst it's important to know when and where to use a particular best practice, it's also important to know when not to use a best practice.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I'm sure we've all seen the job adverts for "rock star developer" or "programmer ninja". I'm sure (hope?) like most of my peers, we've sighed with exasperation as such silly, ego fuelled job titles. Thankfully this article[^] instils some much needed sanity on such job titles.
I particulaly liked this quote.
Quote: I’m more akin to a librarian, scientist, artist, and carpenter. Couldn't have put it better myself. He sums up perfectly the blend of skills needed to be a good software developer.
As a professional software developer, I completely divorce myself from such job titles. I take what I do seriously and carry out my work with due diligence and pride. What I don't do is give myself overblown job titles which do absolutely nothing to enhance my reputation or my profession. Can you imagine seeing an advert for a "rock star airline pilot" or "ninja brain surgeon"? These sorts of titles do our industry no favours whatsoever. How can we be taken seriously when we have adverts for facile roles such as these?
Do you really want a "rock star developer" designing the security component of your enterprise application? Or heading up the implementation of your safety-critical flight navigation system? Or near your business critical on-line payment system? Hell no! These are roles where you want a safe and experienced pair of hands. People who have spent years in the trenches and got their hands dirty sorting out complex programming problems, designing software that works in the real-world, keeping screaming customers happy (or trying their best anyway).
Let's be honest, software developers love doing what we do anyway. We're a passionate lot and enjoy developing software for its own sake. We're geeks. We don't need to be enticed and seduced by silly job titles. And to those that are, stay clear of them. They're more concerned with stoking their egos than doing great work.
A personal plea to any recruiters or head-hunters who may be reading this. Please stop using these job titles. They're silly, unnecessary and trivialise the work that we do.
Our industry doesn't need "rock star programmers" or "programmer ninjas". Seriously, if this is how you see yourself, then please find another career. Our industry doesn't need you. It needs people who are dedicated, passionate, hard-working and take their work seriously.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I think back in the day, everyone was just a "programmer", and that was good, and that was fine. Now, everyone wants to be a comic book hero.
Great post. 
|
|
|
|
|
When I got my first job as a junior programmer all those years ago, all I wanted to be was a good software developer. To get better at what I did, get better design skills, coding skills, debugging skills etc. And as you say, that was good enough. I'm actually perplexed as to where this new found desire to be a "rock star programmer" has come from, and why.
Thanks for the positive feedback
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I recently read the following article[^] with interest. If you are asked a question in an interview and give an unexpected (but correct) answer, should this be seen as a positive or a negative?
In the article, the interviewer seems to mark the candidate down for giving an answer that is different to the one they expected. Whilst I accept that the expected answer in this particular case may be the one that conforms to better design practices and use of the language, the answer nonetheless still solves the problem, and this surely is the point.
The candidate is asked to solve a problem, for which there is no seemingly straight-forward solution. The candidate therefore proposes an alternative solution. In software, you cannot always just re-design the software to implement a new feature. Having the time will also likely be a luxury you don't have. Sometimes, just sometimes, to get the ball past the post, you need to take a different approach, however unpalatable that approach may be.
As long as the candidate made it abundantly clear that whilst the approach they have described is a quick fix and not the preferred approach (and would probably require technical debt at a later date), then giving an unorthodox answer shows both creativity and a deeper understanding of the language than the candidate who simply says it cannot be done.
I would prefer the candidate who solves problems than those who don't.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Dominic Burford wrote: I would prefer the candidate who solves problems than those who don't.
and so does Google.
It has been my experience that open minded and flexible hiring practices, end up being a win-win for everyone involved.
|
|
|
|
|
It's that time of year again, when the Stack Overflow Developer Survey 2016 Results[^] are revealed.
It's no surprise to see Javascript as the most popular technology, with the rise of frameworks such as as React.js and Node.js.
I'd love to know who those developers are who self identify as "rockstars" and "ninjas". Even if you recognised that you were a good developer and better than most of your peers, would you seriously identify as one of these types? I think some egos need bringing down. However, it's reassuring that most developers self identify themselves as "developers". Phew.
The industry is still very heavily dominated by men with over 92%. I feel this is a serious issue that needs to be addressed. We need to get more women into our industry. It would be far better for it. That said, women do occupy creative roles such as designers which is encouraging.
Check out the article (linked above) in full and see what think. Feel free to leave a comment.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
After looking at the survey results a few times, I have to question its accuracy, really.
Also, what's a "growth hacker"? I'm going to have to look that one up.
Everyone I have ever talked to, hates Javascript, yet it is the most popular technology. I know the younger generation uses Javascript more than the older generation, based on my personal experience. I also know that the younger generation can't debug 5 lines of code to save their life, either - again, based on my personal experience.
I don't work with Javascript much, but I have been told, that it is very difficult to debug javascript well. If this is true, then it would explain why the younger generation like Javascript, because they sure as hell don't like debugging.
Interesting. All of it. Very interesting, indeed.
|
|
|
|
|
I too wondered what a "growth hacker" was. Not sure I like the idea of the word "hacker" being used anywhere near our industry as it has very negative connotations.
In my personal experience, javascript is used equally by younger and older generations alike. As it's the language of the web, we don't have a choice in the matter. If you develop software for the web, then you'll need to use javascript.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I was reading an article recently written by a software developer on how he remained creative and focussed. He outlined several techniques he used to allow him to stay creative so that he could be more productive. Apart from being an inherently logical endeavour, software development is also a creative process. Coming up with solutions to solve problems with limited resources and often a rigid set of tools and within tight deadlines and fixed budgets necessitates a high level of creativity.
This got me thinking along similar lines. So here's a list of techniques I use to stay creative and focused.
1. Take a lunchtime walk at the office. This helps clear the head and allows a little downtime too. If you find yourself scratching your head trying to solve a problem, then often a simple walk will clear the head and allow you to re-focus when you get back.
2. Spend time with nature. Yes this may well sound very hippyish, but it's important to spend time in the natural environment. This can be during work or outside of work. Go for a stroll, a run, a bike ride or whatever.......but do it alongside Mother Nature. A stroll to the shops along a busy road is okay, but you really need to be exposed to the natural environment to really get the full benefit. Trees, birds, plants, cows in the field.....you get the idea.
3. Do something creative. Draw a picture, write a poem, write a story, anything that gets the creative juices flowing. You don't have to be any good at these things, that's not the point. The point is to spend time doing an activity that is creative. This in itself opens different pathways in the brain that you can channel to powerful effect.
If you have your own techniques for staying creative and / or focussed, I'd be keen to hear them
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I came across this article recently Let's stop talking about quality[^] and found it really interesting. Whilst I can see exactly where the author is coming from, that different people tend to focus on different aspects of quality (usability, number of defects, code quality). Taken this way, quality is clearly an abstract concept where there will be little in the way of common ground between these different people.
However, if all of these factors are documented from the very begining and are part of the requirements specification, then this should prevent such discussions from arising in the first place. If everyone's definition of quality is taken into consideration from the outset (and of course there will be trade-offs and compromises) then this at least addresses the concerns that someone's definition of quality is not being met.
Whilst you can't keep everyone happy all the time, by at least considering their concerns and agreeing sensible compromises for how they can be met, this should ensure that a higher degree of satisfaction amongst the team is reaslised.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I was reading an article recently that was comparing different programming languages, and it got me thinking about what criteria should we expect in every programming language. There seems to be an upturn in the number of new programming languages, from the mainstream to the obscure. Every week it seems that a new programming language is getting released. So what qualities should we expect in a programming language. Here's my list of qualities.
- A programming language must be predictable. Fundamentally a computer program is an expression of an idea written in a language that can be understood by a computer. It’s a medium for expressing human ideas and having a computer execute them, so it’s critical that a human’s understanding of a program actually be correct.
- A language must be consistent. Similar things should look similar, different things different. Knowing part of the language should aid in learning and understanding the rest. This sounds obvious, but it cannot be understated just how important consistency is in aiding the development of sophisticated programs using a particular programming language. It should also be consistent in how it implements a particular programming paradigm. For example, if the language is object-oriented or functional, then it should be consistent with that particular paradigm, such that a programmer with experience with the paradigm can learn the language with reference to previous knowledge and / or experience of the paradigm.
- A language must be concise. Or to put this another way, a programming language should NOT be verbose. If it takes numerous lines of code just to output "Hello world" to the standard output device, then it can hardly be described as concise. New languages exist to reduce the boilerplate inherent in old languages. (We could after all write machine code. Whilst this would be extremely concise, it would be incomprehensible to a human being). A language must therefore strive to avoid introducing new boilerplate of its own.
- A language must be reliable. A programming language is a tool used to solve problems, it should not create more problems of its own. They should minimise any new problems they introduce. Any “gotchas” are massive distractions.
- A language must be debuggable. When something goes wrong, the programmer has to fix it, and we need all the help we can get with this. The programming language should provide useful error messages, stack traces etc to enable the programmer to debug and fix the problem with the code.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|